??? 05/23/09 17:51 Read: times Msg Score: +1 +1 Informative |
#165557 - Over optimisation. Responding to: ???'s previous message |
Hi Erik,
Thanks for your thoughts but I have identified the problem now - a C51 compiler optimization "feature". I documented this find on the Keil forum, so for sake of completeness I am posting it here too in case it helps anybody else. After a day of searching I have finallly resolved the problem. It is, specifically, C51's rather agressive optimization. Taking the default level of 8, described as "Reuse common entry code" in the "Options" dialog and "Common Tail Merging" in the online documentation, created a helper function that it placed in the code space I was writing to. Even though the two "common" calls were syntacticaly different C51 optimized them and placed a helper routine in memory where I was loading new code to. The two calls, which were located in seperate modules are: write_flash_byte(add++,*ptr++,0); and write_flash_byte(add,*ptr,0); add++; ptr++; In the second instance I had deliberately placed the increments outside the parameter list as I wanted to ensure the code was as "simple" as possible, and I had used the userclass pragma so I could direct the linker to place high in memory, way from where I was writing the new code to. |
Topic | Author | Date |
MSC1210 FlashCode Memory write problems | 01/01/70 00:00 | |
watchdog, interrupts? | 01/01/70 00:00 | |
MSC1210 FlashCode Memory write problems | 01/01/70 00:00 | |
I do not know your chip, but | 01/01/70 00:00 | |
Over optimisation. | 01/01/70 00:00 | |
case for asm | 01/01/70 00:00 | |
asm in Keil is not accepted very well | 01/01/70 00:00 | |
to asm or not to asm | 01/01/70 00:00 | |
Horses for courses. | 01/01/70 00:00 | |
Not that it applies to THIS case ... but ...![]() | 01/01/70 00:00 |