On Mon, Mar 26, 2012 at 02:26:07PM +0200, Jeroen Peelaerts wrote: > > Thanks for your reply. I'm sure that the flash is not empty, it contains > the original firmware of the device which boots up correctly.
OK. Then the next step should be to get a dump of the correct memory area to display the flash contents. > So in this case it should not be write protected as it reads contents from > the flash during the boot proceess? Or maybe it is locked again after the > boot process is complete. It may well be write-protected after reset - to boot from flash, you only need *read* access. The existing bootloader may well re-program the chip select registers to allow writes if it needs them for flash identification or upgrade. > Maybe I can try to reset and halt it directly > to make a dump of the flash memory? That would be a good idea - are you currently letting the bootloader run and then stop the target? In that case, you do not know what state the target is in. The bootloader may have re-configured everything (maybe moving the flash start address somewhere else than the reset default!). > The flash chip is a single Intel TE28F160 chip which has the Advanced > Bootblock flash functionality, which is described in the openOCD > documentation. I can try to issue a flash protect 0 on the flash before > querying it. (documentation states that this type of flash memory > probably needs to have this command issued) That is required only if you want to change data in flash. However, if a dump does not show the firmware contents, trying to write to the flash (to get the ID/CFI data, or issue other commands) is not going to work. cu Michael ------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure _______________________________________________ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
