STM32L4R7ZIT program download or program start problem

[NArnd]

I am posting the support ticket here as well, because it took six weeks to get a first response to the original support ticket.

It is likely related to the issue reported in this posting:

https://community.st.com/s/question/0D53W00000raYd2SAE/intermittent-break-at-address-0x1fff51f4-with-no-debug

@ST: please pick up case 00140083.

This is probably related to the issue I reported in case 00133376. You have closed that ticket so I must create a new one. STM32L4R7ZIT.

I have followed the recommendation in case 00133376 and applied the PEMPTY patches described here:

https://community.st.com/s/question/0D53W00000raYd2SAE/intermittent-break-at-address-0x1fff51f4-with-no-debug

At first, it seemed that our custom init function (replacing HAL_Init() and SystemClock_Config()) had solved the original problem.

Then a colleague joined me in the project and started having debugging problems. We then applied the PEMPTY patches and it seemed that the problem had gone away.

However, after adding more code to the project, we now experience a slightly different problem:

We have a test program that writes a triangle on an LCD screen. We start the execution with the ST-Link v2 attached by clicking the RUN button in CubeIDE. It:

* compiles the project

* communicates with the target (dongle LED flashing) and LCD screen powered off

* the old code then restarts (which can be seen on the LCD screen counter text) and runs for less than a second

* communicates a second time with the target similar to just before and starts running the new code (without interruption)

* the RCC->CSR content at this point says "pin reset"

To the support ticket I attached a video clip that shows the behaviour.

It's the same with CubeIDE 1.6.1 with the PEMTPY patches, with CubeIDE 1.7.0 without and with the PEMPTY patches, and with ST-Link v2 firmware versions V2.J37.S7 and V2.J38.S7.

Once the dongle takes control of the target it should not release it until the new code is downloaded properly.

If connecting power to the board without the dongle attached, it starts running the code and after a few seconds it restarts. However, never more than once. We have not in any way configured or started a watchdog. Since I wrote the power and clock initialization code (after reverse-engineering HAL_Init() and SystemClock_Config()) I know exactly what is done by our code. Nevertheless, it seems very much like a watchdog timing out _once_ after the first reset (including power-on reset), but if this is the case the watchdog must be started by ST's system memory code or before the entry into the main function.

Best regards

Niclas

[TDK]

> If connecting power to the board without the dongle attached, it starts running the code and after a few seconds it restarts.

Custom board? Sounds like it could also be a BOR event. Monitor the power rail and the NRST pin on a scope. Note that the "pin reset" flag is almost always set, but other more informative flags can be set at the same time.

If the issue occurs without a debugger attached, doubt the debugger is at fault here.

> We have a test program that writes a triangle on an LCD screen.

If you're debugging an issue, consider reducing the scope of the program to something that involves less components. Toggle a pin during startup, or similar, to isolate the issue.

[NArnd]

I think jvisser (who apparently spent a lot of time investigating this) is on to the problem in the currently latest posting in the other thread:

https://community.st.com/s/question/0D53W00000raYd2SAE/intermittent-break-at-address-0x1fff51f4-with-no-debug

It appears that the memory mapping is incorrect. I tried his suggestion to uncomment "#define USER_VECT_TAB_ADDRESS", but it makes no difference in my case.

-

A BOR event does not explain why the ST-Link v2 program download resets the target twice, first causing a restart of the old program and then a fully working start of the new program. If there were any problem (caused by bad target HW) during an otherwise correctly built programming sequence, the programming functionality should abort altogether with an error message.

Also the fact that the device seems to function properly after the auto-restart suggests that this isn't caused by HW. (And ST has already provided a patch. I suspect that there are additional bugs still in need of fixing.)

However, I assume ST is using a watchdog in their system memory code that resets the target in case of an error during bootloading. My guess is that ST has messed up the start-up code so that it initially runs part of the system memory code and (after starting the bootloading watchdog) jumps to the flash memory code that still contains the old code. Then the watchdog expires, causing a reset that the second time leads into the correct program download functionality. But this is just a guess that would make sense of what I see and others report.

[waclawek.jan]

> To the support ticket I attached a video clip that shows the behaviour.

This is a primarily user-driven forum with casual ST presence. If you've been handled by ST staff, it's unlikely somebody else from ST will chime in here.

In other words, if you don't provide enough information here, our answers are akin to reading from the Crystal Cube. Describe briefly your hardware and software.

> If connecting power to the board without the dongle attached, it starts running the code and after a few seconds it restarts.

I would start here. This indicates, that the problem is not directly related to programming, rather, it's your program or hardware. Use traditional debugging methods to avoid the debugger/dongle - indicate code progress on pins, observe using LA; use serial printouts. Observe power supply and reset pin using oscilloscope (note that reset output pulse may be very short).

As TDK suggested above, simplify, dissect.

> I tried his suggestion to uncomment "#define USER_VECT_TAB_ADDRESS"

So, you're using some sort of custom bootloader? You might want to accuse that, and/or tell us more about it too.

JW

[TDK]

There are multiple issues you're reporting. Let's focus on the one that happens without the debugger attached. I don't see how that would be related to USER_VECT_TAB_ADDRESS.

> However, I assume ST is using a watchdog in their system memory code... causing a reset

Test that assumption. The RCC_CSR bits will report the reason for the reset. Read these out and report them on a UART or similar stream that doesn't involve the debugger.

My guess is ST has not introduced a hardware flaw where the chip resets a few seconds after being powered up.

> A BOR event does not explain why the ST-Link v2 program download resets the target twice

The debugger resets the multiple times while starting a debug session. Once while programming, and another 1-2 times when starting the debug session. But these events are relatively close together, not several seconds apart.

[Tesla DeLorean]

The memory mapping at zero is driven by the internal boot logic within the STM32L4, the CPU resets SCB->VTOR to ZERO

It is designed so a device with blank/corrupt flash will fail-over into the ROM's System Loader.

You should be changing that either in SystemInit() or Reset_Handler, or your Debugger Scripts. Being zero is the reset state, and the application really shouldn't care/depend on what is mapped into zero-page memory.

I've long suggested (decade+) ST stop with this #ifdef stupidity, and use the linker and symbols to set SCB->VTOR to reflect the address the image is compiled/linked to live in, as this is distinctly more 1D1OT proof.

ie SCB->VTOR = &__Vectors;