STM32L151RD inexplicable/weird crash

[andrei]

Posted on October 03, 2013 at 17:15

Hi,

I developed an application using the STM32L152D Evaluation board and everything was working as expected. The application was then moved to the actual project which uses a STM32L151RD microcontroller. When I try to run the program it doesn't even enter main.c it crashes and the debugger shows it stopped at an out of boundary address(not always the same address) like 0xEE1245 Using breakpoints I managed to find that the crash happens after running the

SCB->VTOR = FLASH_BASE | VECT_TAB_OFFSET; /* Vector Table Relocation in Internal FLASH. */

line in the system_stm32l1xx.c file. I built a new project, with just a toggle on one of the pins and I get the same behavior. With any of the projects there is no crash if I run it from the RAM memory, it happens only if the code is located in the Flash. Any ideas are appreciated. Thank you, Sebastian #- #stm32l151 #flash-error

[Tesla DeLorean]

Posted on October 03, 2013 at 17:29

If you think there flash is a problem you need to revisit the setting for it (wait states, prefetch), and the clock speeds and voltages.

Review the addresses being compiled at, and the content/placement of the vector table. Disassemble the built code if not sure. Is this running from boot, or being called by a boot loader? If the latter make sure all interrupts previously enabled have handlers. That the vector table is on a 512 byte boundary.

[andrei]

Posted on October 03, 2013 at 18:49

Hi,

Thank you for your quick answer. I'm not sure what the problem is, but I'm assuming Flash.I'm using the ST provided library and the crash occurs before any intervention of mine in the code so I'm assuming everything is correctly set up. Moreover the project works just fine, without any changes on the development board (except the obvious change of micro used, from STM32L152 to STM32L151). Any chance of this being caused by an error due to the layout/connection on the microcontroller's pins? I've checked the BOOT0 pin and it is correctly connected to GND.No I don't use any bootloader.Regards,Sebastian

[Tesla DeLorean]

Posted on October 03, 2013 at 19:05

Any chance of this being caused by an error due to the layout/connection on the microcontroller's pins?

Sure, I'd suggest it's far more likely that the connectivity, layout, soldering, of a board to be at issue than the flash in the part. Check that all the supply pins are attached, and voltages, check bulk capacitors. But we know nothing about the board, or the thoroughness of the design. How does the wiring of the part differ from that of the working dev board? Schematic?

[andrei]

Posted on October 03, 2013 at 19:21

The wiring is obviously different on the project's PCB from the dev board. Unfortunately I cannot provide a schematic.

I checked the voltage and it is 3.0V as expected. I checked the clock and it is working and I checked the reset to make sure the board isn't held in reset and it isn''t. How can a layout/schematic error cause an error so specific? The part is an WLCSP64 ball-out so soldering problems can arise but I would've expected it not to work at all in that case, not give such an error.Thanks,Sebastian

[Tesla DeLorean]

Posted on October 03, 2013 at 21:11

I really don't have enough data to make a diagnosis, how about a partially redacted schematic showing the pin connections of the CPU?

What tool chain are you using? Have you set the targets appropriately, with differences in memory size accounted for? Is the stack placement correct? Is SystemInit() trying to return and the stack is all hosed up pulling random junk? You should look and step through the disassembly view. Can you disable ''run to main'' and step around? How about removing a lot of code from SystemInit()? The chip will start running from FLASH, and with a default clock, it should keep running in that mode. The vector table should also be zero by default, and mapped to FLASH, changing it shouldn't cause any problems unless the value is wrong. Try building without optimization, it will make the code linear and easier to step through. The amount of code from the ResetVector, to calling SystemInit(), to the end where it sets VTOR, should all be fairly limited. Are the crystals/external clocks the same? If not you'll need to modify the PLL setting to accommodate. Can you X-Ray the part? Do you have via-in-pad?

[andrei]

Posted on October 04, 2013 at 12:25

Hi,

I fixed the problem. The eval board used an external 8 MHz oscillator while my PCB had an 16 MHz one. I wasn't aware that the system_stm32l1xx.c is a file that has specific settings for projects, I thought it is provided by ST and only has default settings. Apparently there's an excel file that generates the system_stm32l1xx.c aswell, I wasn't aware of that and I didn't find references to it anywhere except... system_stm32l1xx.c Can anyone explain why the software worked while running from RAM?Thanks,Sebastian

[Tesla DeLorean]

Posted on October 04, 2013 at 12:48

RAM cells are very fast, certainly capable of >100MHz operation in the process used to manufacture these devices. FLASH is slow, nominally 35-40 ns. Any critical path issues are going to be far more apparent in accessing FLASH, as increasing the clock doesn't make it respond any faster.