Same Set of Code build with different Compiler not working in stm32l053 controllers

[LRPS_92]

Posted on October 30, 2017 at 14:53

Hi,

I've finished building same code for a stm32l053R8 low power project using both IDE's Keil Microvision 5 & Atollic truestudio v5.5.2. Keil MicroVision project build works fine in all of our boards which we designed for the project. But Atollic build not working in some of our boards.

By switching the power, controllers flashed with keil microvision project .bin are starting from the main easily at the first attempt itself.

But, Atollic build .bin file is not getting into the main at the first attempt( requires NRST from debugger manually to reset properly & start from the main code). I've tried debugging using Atollic IDE, but it works fine, the code jumps to the main. Without debugger connected the codedoesn'trun.

What may be the reason for this kind of behaviour in controllers.?

Thanks in advance

#boot #stm32l053 Note: this post was migrated and contained many threaded conversations, some content may be missing.

[AvaTar]

Posted on October 30, 2017 at 15:15

I've tried debugging using Atollic IDE, but it works fine, the code jumps to the main. Without debugger connected the code doesn't run.

Dunno the Atollic IDE in detail.

My preferred IDE (Crossworks / ARM) uses a special startup code in the debug configuration, that waits in an endless loop for the debugger to connect.

I suggest to check if the Atollic Debug setup does the same.

[Tesla DeLorean]

Posted on October 30, 2017 at 16:10

Iteration bounded loops in clock startup code? Ends up in error handler or hard fault handler in a while(1) loop?

Instrument code so you understand where it is stuck, or how far it got. Use GPIO or USART initialized right in Reset Handler. Add check points so you can evaluate without a debugger.

Check for dumb things in the linker scripts, like setting stack pointer to an odd address, ie initialsp = 0x20001FFF, the CM0 hates unaligned reads.

Assuming a custom board, look at how supplies ramp, and if you need a better POR circuit to clamp device in reset for longer, or until supplies get higher, ie >100ms

Make sure BOOT0 is pulled low in your design.

Keil is a better tool, doesn't use GNU/GCC compiler, free for ST CM0 parts.

[AvaTar]

Posted on October 31, 2017 at 08:10

I would check as well if the Atollic project contains the proper linker script for your exact MCU variant.

Invalid address range would have the observed result.

[LRPS_92]

Posted on October 31, 2017 at 10:00

Hi,

1. I'm not using any iteration bounded clock startup code.

2. Linker Script (.ld) looks fine too from what i've seen, attached it for your consideration.

3. Using 3.6 V to power up the board, NRST is pulled high with 10 KOhms resistor & 0.1 microFarad Connected to ground in our custom board ( Which is around 1 ms? ). Crosschecked working & not working boards,all the boards do have the same hardware setup.Used 2.2 microFard & 100K resistor combination on NRST pin also ( which is around 220ms), no change in result.

4. BOOT0 is always grounded with 510 Ohms resistor.

Will check & post whether the reset_handler called before entering main by initializing GPIO's / USART.

________________ Attachments : STM32L053R8_FLASH.ld.zip : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006Hy9i&d=%2Fa%2F0X0000000b6D%2Fj2xgTyoGmCkMR6rT4nRucxTfqbHufUDthxIYKg0nZog&asPdf=false

[LRPS_92]

Posted on October 31, 2017 at 10:14

Hi,

          I've generated the pheripheral drivers, startup file & linker script using MX Cube for the Atollic project. Same controller part number used to generate code.

[AvaTar]

Posted on October 31, 2017 at 10:24

Like other here, I do not speak Cube.

In your initial post, you said:

Without debugger connected the code doesn't run.

How is this statement qualified ?

The code may crash after entering main.

If you need to pursue this issue, you can instrument your code, and watch the outputs.

Maybe an UART, but even a simple GPIO will do.

[LRPS_92]

Posted on October 31, 2017 at 10:30

Yes, By not connecting ST-Link debugging tool ( simply a discovery board ) the code doesn't run on its own at every power reset. If ST-Link debugging tool is connected with the board same problem arises, though it clears after resetting through Reset button provided in the ST-Link debugging tool (discovery board)

[AvaTar]

Posted on October 31, 2017 at 11:13

Yes, By not connecting ST-Link debugging tool ( simply a discovery board ) the code doesn't run on its own at every power reset.

How do you know that ?

How do you discern this from an application crashing/hanging early, like in the clock setup ?

[LRPS_92]

Posted on October 31, 2017 at 14:02

That was a good question. I'm using tiny_printf re-targeted to a USART. I have prints which are starting from the main code. So, I will know whether the program entering the main or not. Before main, I couldn't able to check using prints so trying to add

GPIO's i

nside the reset_handler.