Bryce Schober's Profile

h LPC2136, in general good with syst

r Application Engineer in the Embedded Systems Division of Mentor Graphics, talks about embedded eystem

I think I've found the bug explaining the only unexplained problem: the failed backup of v4 software w/ v5 loader.

In v5, the Sharp7 mmu was configured for the larger 4MB flash, where in v4 the mmu was configured for a 1MB flash. The v5 loader uses a flash_device_size() function to read the correct size from the part itself, and limits writing beyond the physical extent of the flash, including in the read_flash_block_by_addr() function that otherwise reads too far ( see case 15241 ). The problem is that the loader does not configure the MMU, it depends on the application's boot code to do that. So when the v5 loader runs from v4 application, the current implementation of read_flash_block_by_addr() is allowed to run past the end of the configured 1MB of flash, since the inside of the loop is only limiting to the actual physical size of the flash, not the mmu-configured size of the flash. Therefore when the SP reads from the last block of flash and it goes one byte too far, it causes a pre-fetch abort, and the Sharp7 locks up in the loader. So when case 15241 is fixed, this behavior will go away.

place Deshaker.vdf under the VirtualDub plu