Posted on May 09, 2006 at 10:32Hi,
I am working on a dual-ST10F269 system (although the dual-ness can be ignored from hereon in) that is usually programmed by flicking a switch into a specific position which pulls P0.4 low and makes the ST10 processor boot from serial mode to program the on-board flash memory. The problem I have with the latest incarnation of our system is that we no longer have physical access to these switches, we can only access the serial port. So I needed to make some special bootloader program that resides at the beginning of bank 0 in flash memory and, depending on some condition, either jumps to the normal functioning application resident in flash memory, or mimics the on-board serial bootloader by doing exactly what the on-board serial bootloader does.
The implementation (for testing at the minute) is that the system starts and the flash BL listens for the 0x00 byte sent by your ST10 Flasher Tool. If that is not received within 10 seconds then we make a jump and normal operation continues. If the 0x00 byte is received then we respond with a 0xD5 to identify ourselves and wait for the next 32 bytes received on the serial port. These 32 bytes are copied to location 0xFA40 in on-board RAM, and then a group of registers are set to the necessary values stated in the ST10F269 datasheet, and we then jump to 0xFA40 to continue as it would do in on-board BL mode. From that point on I'm out of the equation.
Now for the problem ...
The ST Flasher Tool loads well and the monitor loads successfully. However if I try to erase a portion of flash memory then the command to erase a block is sent to the processor, but I never get any response.
Remember that at this point the Flasher is talking to its monitor which is loaded on the ST10 processor, and I am out of the equation. So this is nothing to do with my software, other than I must have not set something up correctly in the first place for the world to continue when I hand over control to the Flasher's primary bootloader (the 32 bytes in RAM).
So when the command is sent to erase flash block, say, 2, it gets a response from the monitor saying that's fine (I think it's 0x70 more than the request but I can't remember), and then the Flasher says 0xFE 0xCA to acknowledge the erase operation. Then the monitor should erase the block and confirm to the flasher that the operation completed successfully (or not) but it just hangs forever. So there is something in the monitor software that must receive the command, recognise it as an erase operation, convert the block number into explicit physical start and end addresses, then perform the STEAK erase operation. The fact that nothing is ever returned from the processor implies that this function MUST also be waiting for some condition to be met before it continue with the operation, but it is only possible to know this by using an emulator or by looking at the source code for the monitor because it happens inside the monitor itself.
I obviously don't have the source code, and I don't have a 168 emulator either, but if I had a 168 emulator (which I don't) then I would attempt to erase the block, then wait for a second or two and hit stop in the emulator and see what condition was being looped on. I suspect it is just a register that needs to be a specific value as it can't be something ''physical'' like a lock on the flash memory witing to be released because this all works with other flashers that I've tried to use. However with nothing about this in the datasheets I think this is only answerable by somebody with the source code.
