Reset function on STR910-EVAL

[yuhleon]

Posted on July 18, 2008 at 09:49

Reset function on STR910-EVAL

[akaiser9]

Posted on May 17, 2011 at 09:41

Different idea: When the IAP, executing from RAM, switches to the application, it:

- disables the application (non-boot) bank, - configures this bank for addresss 0, - disables the IAP (boot) bank, - does *not* remap the boot bank, - enables the application bank, - then jumps to address 0. Of course, the IAP/boot bank must stay disabled or we get a bank address conflict. It is a similar situation as on power-up, where both banks are configured for the same address but only one of them is enabled. In this case, the non-power-up reset disables the application bank, enables the boot bank and the IAP gets into control just as it does in a power-up reset. Looks pretty much as if it were actually designed that way, just not properly documented.

[mydani]

Posted on May 17, 2011 at 09:41

Hello Prx,

I know this thread is really old - BUT! I'm currently struggling how to design my bootloader/application handlung. Did this solution you wrote above work with both kinds of reset? (Mapping both banks to 0x0 and disabling one of them at a time...) Else I have to continue thinking of keeping the complete vector table in RAM. Thanks! Regards, Daniel

[kbsu-2]

Posted on May 17, 2011 at 09:41

Quote:

On 20-04-2007 at 17:39, Anonymous wrote: Different idea: When the IAP, executing from RAM, switches to the application, it: - disables the application (non-boot) bank, - configures this bank for addresss 0, - disables the IAP (boot) bank, - does *not* remap the boot bank, - enables the application bank, - then jumps to address 0. Of course, the IAP/boot bank must stay disabled or we get a bank address conflict. It is a similar situation as on power-up, where both banks are configured for the same address but only one of them is enabled.I tried to do so and i got a ''fantom'' intstructions fetched from flash. STR91xFA Errata Sheet:

Quote:

Description of limitation in revision G

There are two independent Flash memory banks (primary and secondary) that allow readwhile-write capability from one bank to the other, enabling In-Application Programming (IAP) of the primary bank while executing code from the secondary bank. After IAP has upgraded firmware in the primary bank, the bootloader code in secondary bank should remap the banks by writing to FMI registers FMI_BBADR and FMI_NBBADR in order to have the primary bank start at address 0x0, which allows interrupt handlers to reside in the application code primary bank instead of interrupts being handled by bootloader code in the secondary bank. There are two forms of reset in the STR91xFA. A Global Reset (from power-up or voltage drop-out) that clears all functions in the device, and a System Reset (from reset input pin, watchdog, or JTAG reset command) that clears all but a few configuration registers. Silicon Limitation: The remapping operation is possible. However, when a System Reset occurs after the remapping, the application hangs because the FMI_BBADR and FMI_NBBADR registers which define bank locations are not cleared by the System Reset, while the FMI_CR register which controls the Chip Select enable of the non boot bank are cleared by the System Reset. Workaround using revision G Do not remap the banks after IAP (keep secondary bank at address 0x0), and in the secondary bank redirect ARM interrupts to be handled in the primary bank. This limitation is fixed in revision H devices by clearing all FMI registers (including bank base address and bank size) after a System Reset.