JTAG flash programming is *painfully* slow. I reckon that flashing a 16Mbyte file using JTAG on the Simpad at the 'normal speed would take about 24 hours (or more?). My method achieves almost the same result, but uses the 'erase block' function to clear the flash more quickly. That said flashing the contents of the flash to 0x00000000 would always be better than erasing the flash blocks (to 0xFFFFFFFFFF

? or whatever ?), as 0x00000000 corresponds to the ARM instruction :-
ANDEQ R0,R0,R0 ; this is effectively the same as a NOP instruction.
So if this 'code' was ever run in error, it would not do anything 'dangerous', but eventually I guess that an ARM memory exception would occur ??
Ralph
Why don't you create a file with 16 Mbytes of 0x00 and flashmem it in one step?
I suppose flashmem 0 16mbfile erases the first bank, while flashmem 0x1000000 16mbfile erases the second bank. Haven't tried it, though...
Digi
There are times when even re-loading the Siemens 2.4 SL bootloader with the JTAG utility does not appear to recover a 'bricked' Simpad. For example loading the Siemens 2.4 CL bootloader into a Simpad SL appears to be a good way of 'bricking' your Simpad ! (I tried this just to see what happens).
I found that JTAG (version 2.4) supports a scripting option. So I created a file called 'null' with the contents of just 4 bytes (0x00 0x00 0x00 0x00). Then used the following script file to write this data into every block of the first 16-bit flash chip. During the flash process, all EEprom flash blocks are first erased, so the script below effectively erases the 16-bit 'accessible' flash chip that is used to hold the boot-loader.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=118166\"][{POST_SNAPBACK}][/a][/div]
[div align=\"right\"][a href=\"index.php?act=findpost&pid=118173\"][{POST_SNAPBACK}][/a][/div]