Dear Tom,
In message 4959A41F.50701@ceos.com.au you wrote:
| commit 9d803d8c0b7fd9aeb2e708e9e48dd76d7287856d | Author: Markus Klotzb^(n)cher <Markus Klotzb^(n)mk@pollux.(none)> | Date: Wed Feb 8 18:56:28 2006 +0100 | | Changes: | | * lots of bugfixes in the assembler code | * reverted hardware.h back to original | * enabled hardware DRAM calibration | * GCC-4 fix: modified GLOBAL_DATA_POINTER macro
| $ git diff | af646e865f4bc67623ca957dfe3d3e4a95ff0468.. | 9d803d8c0b7fd9aeb2e708e9e48dd76d7287856d | board/zylonite/lowlevel_init.S | ... | + /* mk: replaced with wait macro */ | +/* ldr r3, =OSCR /* reset the OS Timer Count to zero */ */ | +/* mov r2, #0 */ | +/* str r2, [r3] */ | +/* ldr r4, =0x300 /* really 0x2E1 is about 200usec, */ */ | +/* /* so 0x300 should be plenty */ */ | +/* 1: */ | +/* ldr r2, [r3] */ | +/* cmp r4, r2 */ | +/* bgt 1b */ | + wait #300
Note that the linear code has been replaced with a macro.
The comments above the code above state:
/* Step 1: Wait for at least 200 microsedonds to allow internal */ /* clocks to settle. Only necessary after hard reset... */
The bug is that "=0x300" has been changed to "#300", and the latter is interpreted by the assembler as a decimal number. So the code is only waiting for 92us instead of 200 (13MHz clock divided by 4, divided by 300).
I don't know if this causes any problems. The code doesn't match the comments, and it probably isn't following the manufacturer's specification for this timing either.
Anyone else based of the Zylonite port might like to check their code.
I fixed this for the delta and zylonite boards now. Thanks for pointing out.
Best regards,
Wolfgang Denk