STM32F2XX Flash PGPERR and PGSERR set just after reset

[jbookout]

Posted on April 09, 2013 at 20:35

The specific device: STM32F205RG

Issue: I have a small boot code region that I'm using to jump from 0x0800000 to 0x08020000 the intervening blocks are to be used for static data... Unfortunately once I've jumped to 0x08020000 and start executing (even if I just infinite loop) I end up with the PGPERR and PGSERR bits set and if I clear them they just get reset. Code to make the jump from 08000000 to 08020000:

HWM_reset_handler PROC
EXPORT HWM_reset_handler
; Go to boot loader.
ENTRY
ldr r0, =0x08020000
ldr r1, [r0]
msr msp, r1 ; Initialize Stack for boot loader
add r0, r0, #4 ; r0 now has addr of reset handler in boot loader
ldr r0, [r0] ; Load the Reset Handler Address
orr r0, r0, #1 ; Ensure thumb mode
bx r0 ; jump to boot loader image
ENDP
ALIGN

I'm using the RVCT 3.1 compiler and assembler. (RVDS toolchain) So I can't exactly use the ST example libraries except as code examples... I also attempted to set the flash parallelism before making the jump, but this didn't help. I have a feeling it's not related to my code, as I'm not yet writing flash anywhere, rather related to the tool chain configuration...any ideas?

[Tesla DeLorean]

Posted on April 09, 2013 at 20:50

The C compiler should be fine with the library. With the CMSIS version you're going to want to be calling SystemInit() prior to getting to main().

Clearing all the pending flags is standard operating procedure if unlocking the flash. STM32F2xx_StdPeriph_Lib_V1.1.0\Project\STM32F2xx_StdPeriph_Examples\FLASH\Program\main.c

int main(void)
{
/*!< At this stage the microcontroller clock setting is already configured,
this is done through SystemInit() function which is called from startup
file (startup_stm32f2xx.s) before to branch to application main.
To reconfigure the default setting of SystemInit() function, refer to
system_stm32f2xx.c file
*/
/* Unlock the Flash to enable the flash control register access *************/
FLASH_Unlock();
/* Erase the user Flash area
(area defined by FLASH_USER_START_ADDR and FLASH_USER_END_ADDR) ***********/
/* Clear pending flags (if any) */
FLASH_ClearFlag(FLASH_FLAG_EOP | FLASH_FLAG_OPERR | FLASH_FLAG_WRPERR |
FLASH_FLAG_PGAERR | FLASH_FLAG_PGPERR|FLASH_FLAG_PGSERR);
/* Get the number of the start and end sectors */
StartSector = GetSector(FLASH_USER_START_ADDR);
EndSector = GetSector(FLASH_USER_END_ADDR);
for (SectorCounter = StartSector; SectorCounter < EndSector; SectorCounter += 8)
{
...

Why are you looking at the flash status, and why does it matter if you're not writing it?

[jbookout]

Posted on April 09, 2013 at 21:17

Thanks for the quick reply. Sorry for the confusion, I'm sure I could compile the library, but it's not a technical limit it's a 'we write our own drivers and everything else' limit imposed by my company...lame, I know, but also beside the point :). So consider those calls unavailable...

Reading between the lines you seem to imply that the operations SystemInit performs are required for the jump to another block of flash to work... is this correct? I was hoping to avoid all of that setup, make the jump and then setup everything...is this not possible? I couldn't find anything specific in the docs/errata/app notes that suggest this...Clearing all the pending flags is standard operating procedure if unlocking the flash. Agreed, and as soon as I can figure out why they are set so early in the execution (before doing anything with flash) I set up flash procedures to do this...but they must be getting set for some reason right? I'd rather not ignore error notifications I'm being given... Why are you looking at the flash status, and why does it matter if you're not writing it? I was attempting to write flash much later in the boot loader (which is where I initially saw the error bits were set). I traced the cause of the bits being set to well before the flash operations so I didn't mention them.

[Tesla DeLorean]

Posted on April 09, 2013 at 21:42

No, I'm just trying ascertain how broken the start up process is, and why RealView is incapable of compiling fw library code.

Among other things, the SystemInit() sets up the vector table address, clocks, wait states, and PLL. In other situations it also configures FSMC buses, and FPU (!F2) In terms of flash status flags, I have observed different states depending on if the JTAG pod just flashed the device, vs just cold booting the CPU. I've seen a couple of examples where it unlocks, and does a ''wait for last operation'' which breaks if people assume there was some preceding process, and there wasn't or it was broken.

[jbookout]

Posted on April 10, 2013 at 00:24

RealView probably can compile the library code. But I can't add it to my project.

I'm doing most of the things (as needed) that you mention SystemInit() does; however, I'm doing them manually. Except for flash operations it all works fine. I feel something's gone amiss in the discussion though; because, I don't understand how any of your last post is relevant. So lets start fresh and simple: Is it possible to jump from 08000000 to 08020000 without performing any of the setup that SystemInit does and without causing an unclearable flash error bit?

[Tesla DeLorean]

Posted on April 10, 2013 at 01:12

The code you presented, depending on how it's called, should work.

I can't see it having any impact on the flash registers. The following is a minimalistic image situated at 0x08000000 which will transfer control to a Cortex-M3 image situated at 0x08020000

;At 0x08000000, shadowed at ZERO, execution does not start here

DCD 0x20002000
DCD Reset_Handler
;...
Reset_Handler PROC
EXPORT ResetHandler
ldr r0, =0x08020000 ; Base of secondary Image
ldr sp, [r0, #0] ; Load the Stack Pointer
ldr r0, [r0, #4] ; Load the Reset Handler Address
bx r0 ; jump to secondary image
ENDP

If you have to tweak the Thumb bit the linker/compiler have bodged the job of producing a usable Cortex-M3 binary image. If the flash registers are still a problem, you're fighting other demons. You might consider how you execute freshly flashed code, are the caches being cleared, are you doing a reset?

[jbookout]

Posted on April 10, 2013 at 14:13

If you have to tweak the Thumb bit the linker/compiler have bodged the job of producing a usable Cortex-M3 binary image.

Agreed. That code's been in there forever. I haven't tested without it. Probably unnecessary code someone left in.You might consider how you execute freshly flashed code, are the caches being cleared, are you doing a reset? I believe they are...I can't connect JTAG without a power cycle reset...so every time I've seen this happen it's been after a full reset... Unfortunately I have to drop the issue for a day or two...yay software schedules...I'll be back to figuring this out soon though, if anyone has had a similar issue with the RVDS environment and an F2XX I'd appreciate any info...hopefully this issue doesn't magically go away when I come back to it...I want to know the cause.

[Tesla DeLorean]

Posted on April 10, 2013 at 14:28

I'm not convinced RVDS is the issue here.

[jbookout]

Posted on April 16, 2013 at 23:05

Well I've made some progress...

I've discovered that the PGPERR and PGSERR bits are set when the RealView ICE JTAG is used to step through code...my best guess is that my jtag configuration (auto-configured by RealView Debugger) is wrong and attempts to access flash in a bad way when setting break points for stepping... I would love to get the configuration corrected, but haven't the foggiest idea how to match realview's config options to the cortexm3/stm32f205 documentation about the jtag taps... Suspecting this as the issue, I took a step back and wrote a whole bunch of debug code to monitor all the flash registers in local variables for every step I was attempting and after much trial and error (read: slow debugging) was able to get flash erase and write to work... One gotcha some might benefit from knowing is that the SNB bits (sector number) must be cleared after an erase...at least that's the only solution I could find to make two consecutive erases work on the same sector... Essentially I was doing this:

1. Erase sector 7.
2. Write to sector 7.
3. Erase sector 7.
4. Write to sector 7 (different data).

Step 3 wouldn't work without clearing the SNB bits to zeros and setting them again before Step 3... I'm not sure why this is the case... probably some internal HW state machine looking for those bits to change... sort of lacking in the documentation though. So, if you have multiple erase issues, clearing the SNB bits might solve the issue.

Would love it if someone reading has seen the realview system work correctly and can share a configuration or some help configuring it...

[Tesla DeLorean]

Posted on April 16, 2013 at 23:29

So, if you have multiple erase issues, clearing the SNB bits might solve the issue.

As would a review of the library source code, which does clear things out first, and also clears SER when done.Would love it if someone reading has seen the realview system work correctly and can share a configuration or some help configuring it... The pool's a bit shallow here. I did mention earlier that JTAG pods interfere with things. People overly assume they are non-invasive, but they are invasive, so things that can't be accessed transparently via scan chains in the background have to fiddled with by pushing in code and executing it. Peeking at peripheral register being particularly invasive, especially when doing so clears pending status. Generally if you want to validate/debug flashing routines, you need the system to be free standing, and get telemetry out a serial port.