Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
stm32F7 exception after flashing
#11
Hi EmBitz,

You write "Only with faulty code". My EBLinkTest.zip is an example of faulting code.

vdaniel
Reply
#12
Sorry, I thought that that was the executable, I removed it.
Could you add EBLinkTest.zip again?
My mistake, it's early here  Smile
Reply
#13
Ok,

Please, find it


.zip   EBLinkTest.zip (Size: 772.86 KB / Downloads: 4)
Reply
#14
I have to go but a quick test shows that it has to do with the stack.
If you change the _estack in the linker file to e.g. 0x20010000 it runs.

Problem is when it calls SystemInit the first push{r7} traps. 
If the exception is ignored then everything keeps running. Perhaps F7 problem errata? 

This is a device/code related problem. The code runs unmodified on a H7x.
Solution could be, turn off exception but this is normally not something that you don't want to solve.

If I have more time I will look further. 



Code:
(135)  {
08006184 push {r7}
08006186 add r7, sp, #0
(136)    /* FPU settings ------------------------------------------------------------*/
(137)  #if (__FPU_PRESENT == 1) && (__FPU_USED == 1)
(138)    SCB->CPACR |= ((3UL << 10*2)|(3UL << 11*2));  /* set CP10 and CP11 Full Access */
08006188 ldr r2, [pc, #32] ; (0x80061ac <SystemInit+40>)
0800618A ldr r3, [pc, #32] ; (0x80061ac <SystemInit+40>)
0800618C ldr.w r3, [r3, #136] ; 0x88
08006190 orr.w r3, r3, #15728640 ; 0xf00000
08006194 str.w r3, [r2, #136] ; 0x88
(139)  #endif
(140) 
(141)    /* Configure the Vector Table location add offset address ------------------*/
(142)  #ifdef VECT_TAB_SRAM
(143)    SCB->V
Reply
#15
I am sorry, but with the

_estack = 0x20010000;

the same problem
Reply
#16
Full rebuild?

On a F429 it starts running.

Put break on 0x08006184 which is the cause.
Reply
#17
If you face problems like this, the steps to debug this are:

1) turn off "Running to Main"
2) Start code
3) In the system startup put a break to the first external call (systemIni or main etc)
4) Problems for the break? -> memory assignment problems
5) Problems in the call -> stack related
6) problems in the function -> debug functionality
Reply
#18
Yes, full rebuild.

Your recommened steps again does not work.

I use instead:
1) Full rebuild,
2) Program the chip with ST-Link Utility,
3) Start the EBLink from EmBitz in usual way.
4) Have a normal debugging process.

vdaniel
Reply
#19
I get exactly the same when I flash it with STutil and start EBlink GDB in hotplug mode. Also the same exceptions.
Also a file flash compare is exactly the same, so no flash errors

And that unwind isn't lying. If I turn this off with the original code I get the following.
Those flags are there and it jumps into fault handler

   

P.s.  If I flash it with STutil and start the core with STutil it is also looping in hardfault error.

   
Reply
#20
Hi Gerard,

I am a hardware designer and a problem programmer, not a system programmer.
Maybe the EmBitz is mainly targeted for such a kind of users.

I just use this procedure, again with some corrections.

1) Full rebuild,
2) Program the chip with ST-Link Utility,
3) Disconnect from ST-Link Utility,
4) Start the EBLink from EmBitz in usual way.
5) Have a normal debugging session,
6) If code needs correction, correct it and jump to the 1,
7) Finish

It is slightly longer due to the steps 1)...3), but works reliably.

Again great thanks for such a fantastic tool, waiting for the V2,
With the best regards,

Varuzhan
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)