Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
stm32F7 exception after flashing
#1
Hi, I am testing STM32F722.

When before to start the EBLink Debug "Session Start/Stop", I program the chip by ST_LINK Utility, the debugger
works Ok, but when I started Debug directly, I see:

Interface speed: 3300KHz
Target detected: Cortex-M7 (r1p1) with FPv5_SP
HW breakpoints : 8
HW watchpoints : 4
Fault unwind : Enabled
STmicro family : STM32F72x/73x
Detected FLASH : 0x80000
Configured RAM : 0x80000
GDB listening (127.0.0.1 @ 2331)
GDB connected
Flashing sector 0, address: 0x08000000, length: 0x8000
Flashing sector 1, address: 0x08008000, length: 0x8000
Flashing sector 2, address: 0x08010000, length: 0x8000
Flashing sector 3, address: 0x08018000, length: 0x3BD8
Reset: system
Target Exception!

[LR]: 0x080170C3
[PC]: 0x08015658

Additional Info:
User:
-Undefined instruction

vdaniel
Reply
#2
Ok, there is an instruction that cause the mcu to trap.
The same occurred before but that trap was ignored. I changed the unwind to catch all the traps.
How does the code looks like? do you have a meaningful call stack?

Can you share the project (private mail perhaps)?
Reply
#3
P.s I just loaded a project in F746 and that was without any problems. I can't reproduce it. If possible, teardown a project to the fault and share  it with me.

You can find here more info
https://interrupt.memfault.com/blog/cort...ault-debug

In your case UNDEFINSTR flag was set.

Here is an nice document about exceptions 
https://www.keil.com/appnotes/files/apnt209.pdf


If you think that the MCU shouldn't trap, or just what to ignore it, search for something like

  SCB->SHCSR |= SCB_SHCSR_USGFAULTENA_Msk
              |  SCB_SHCSR_BUSFAULTENA_Msk
              |  SCB_SHCSR_MEMFAULTENA_Msk;

and remove the  SCB_SHCSR_USGFAULTENA_Msk setting. I think that that trap, like all the user traps, is  disabled.

-Gerard
Reply
#4
Hi Gerard,

Unfortunately I cannot send my current project.
My code is generated by STMCubeMX. After translation it runs without any trap, both the Debug and Release versions, if I program the chip by the ST_Link Utility.
The programmed chip I can even debug by EBLink, watch variables, set breakpoints, etc.

This shows, that problem is not in my code, but in the EBLink downloading section.

Varuzhan
Reply
#5
Are you using the external bootloader version perhaps?

I'm not setting those traps, I just read them and let them show, so I can't explain and I can't reproduce it. It would be nice to see the code on which it traps.

The CFSR is also cleared on reset by the MCU so that flag is set by something that was executing on the MCU. I can't set that flag.
Reply
#6
Some exception testing for the F4 but also runs on the F7/H7


.c   main.c (Size: 7.35 KB / Downloads: 3)
Reply
#7
Is there perhaps a flash error?
Flash the HEX file by eblink (just via context menu "Flash file") and see if this goes well. Verify is enabled for context menu flashing.
And if this succeeds could you compare the content with STutil and the used HEX file?
Reply
#8
It's important that we tackle this because the unwind is gone play an important rule in the 3.8 version.
Attached the Unwind of 3.8 in the 3.7. The target is automatically checked on exceptions and halted so the code doesn't need to be changed with bkpt's etc.

Also, don't enable the Unallign flag of the MCU, a lot of code of the GCC library is unalligned which will cause exceptions but the code will run, the performance is only much lower.
If all the traps are enabled then it is not so easy to make the MCU happy.
Reply
#9
Hi Gerard,

With your new eblink.zip nothin changed.

I prepared a simple project (does nothing, only compiled), see attached.

The problem is the same as for my main project.

By the way,  I use STLink v3.

Varuzhan
Reply
#10
Have you checked the flash content? we don't have flash issues with EBlink?

No, that version would not change it. That version is catching active the exceptions, normally the exceptions are only evaluated on halt.
If you don't want to use unwind, use the -Tcortex-m,nu cli switch and most likely it will go into a fault handler vector.

The 3.8 version (which is in the Dev branch) has a unwind level instead of switch. the -Tcortex-m,uw=0 turns the unwind off. levels are:
0= Off
1= Forced only  <- Exceptions are only evaluated on halt
2= Active break <- Eblink will check the target active on exceptions and will Halt.

About your issue,
I can't explain it why you have that exception. After Reset that cfsr is cleared and only set by MCU execution. I can't reproduce it and we use the 3.8 (with unwind level 2) extensively on two projects currently, a F0x and a H7x. This new exception handling also discovered issues we were not aware of like misalignment in loops where un32 was aligned as  2 bytes boundary instead of 4. Everything works without that knowledge but if it's an heavy worker loop then it is wise to make it aligned  because of performance gain.

Only with faulty code I can investigate what's going wrong. So it is waiting that others are facing the same and can share it or that we see it here.

To be continued...
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)