search

barafael / g4-dual-bank-example

MIT License
22 stars 3 forks source link

FLASH program address alignment #1

Closed kroppt closed 4 years ago

kroppt commented 4 years ago

My code to test dual bank boot loading ended up being pretty much the same as yours, since there is really only one way to do it. I referenced your code to make sure that I didn't miss anything, but as far as I can tell it's the same.

When programming, there is an error. HAL_Flash_GetError() returns binary 10100000 Bits 5 and 7 (0-indexed) are:

According to the manual RM0440: PGAERR is set if one of the following conditions occurs:

This occurs immediately when writing, where the offset is 0, i.e. address 0x08040000 is 'misaligned'.

I have not been able to find the linker discussion you talked about on the ST community website. Perhaps that is the solution to this.

barafael commented 4 years ago

Have you tried running the code from this project? If you want, I can give you binaries to test, but you can easily compile yourself. The linker file should be like the one in this repo. Otherwise, the second bank image does not boot. But the pgaerr is not because of that. What are the conditions for PGSERR?

kroppt commented 4 years ago

Doh.. one must unlock/lock the flash memory. When I read the documentation I thought that the lack of a "requires unlock" statement means that you don't have to unlock it. I also didn't think of just looking at the linker file in this repository, again doh. Now that I'm on the second bank, I have to figure out this other programming issue, so that I can get back to bank 1.

barafael commented 4 years ago

The discussion about the linker file and system boot loader and so on is here: https://community.st.com/s/question/0D50X0000CEqc1SSQR/dual-boot-on-the-stm32g4-not-quite-working-boot-from-second-bank-fails?t=1591957302322

Glad you found out! The PGSERR hinted at that, I had a slight suspicion :)

kroppt commented 4 years ago

Unfortunately I cannot get it working still. I tried your project, but when I press the button, it reaches the end of the FLASH erase function, on either FLASH_PageErase call or return status. After that, the stack trace is something like (shallowest to deepest):

In retrospect, this is what was happening on my own tests, I just thought that I was getting these issue because of where I placed the FLASH unlock.

I thought it might be your configuration or something like that, so I created a new project and copied the main code over, along with configuring the interrupts for FLASH and GPIO, setting up B1 and LD2. Even then, it still crashes with roughly the same stack trace.

So, I think my problem in fact is something different than what I described in the original post. I was getting errors related to the memory not having been flashed, because I didn't unlock the memory before flashing. It is when I do it correctly that it crashes.

barafael commented 4 years ago

I added the current binary. I really recommend trying if it works with that.

kroppt commented 4 years ago

The binary has the same problem. I was using the ST-LINK Utility, and the the "core state" locks up when I press the button. Since I had it open, I did a full chip erase and the results were still the same.

barafael commented 4 years ago

Do you happen to have other hardware to check?

If you can try with STM32CubeIDE, you could check at which point the lock up happens.

kroppt commented 4 years ago

I don't currently have more hardware on me. I had used STM32CubeIDE before, and as stated above, it would usually happen at the end of the FLASH erase function.

kroppt commented 3 years ago

OK I found that the issue does not happen with another G4. I must conclude that G4 was just broken all along...