On ATSAME70Q21 efc_perform_read_sequence consistently hangs, but only in some builds

Go To Last Post
2 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have this very hard to solve problem. My firmware is running perfectly fine, but some builds won't boot. If I then re-order the linking of the C files or just add a printf somewhere it can be solved and then that firmware seems totally stable. Now I have been investigating what happens and it is hanging somewhere in efc_perform_read_sequence. Using vimdiff and the list file I tried to change things while preventing the entire thing to get re-organized and the bug disappearing. So for instance when I disable the instruction cache (by replacing the Enable with Disable in board_init) the problem is solved while the code layout is not changed. Also when I change the wait states in system_init_flash from 6 to 7 or 5 the problem also is gone, again making sure the code is not completely different. Also I tried replacing the first if in efc_perform_read_sequence (that is never true anyway) by the same amount of nops. The code still hangs. But when I move one of the nops below the first FMR assign it fixes the problem. Two nops doesn't but three does fix and also four fixes the problem. So I am really pulling my hair out... is this a timing issue... alignment issue... a bug in ASF regarding the efc_perform_read_sequence? I do BTW disable interrupts before calling this flash_read_unique_id (the method using efc_perform_read_sequence), something I don't see Atmel do in their examples, but from reading the code sounds like good practice since the whole FLASH address space seems to be temporarily relocated. Anyone suggestions where to look for a solution? Thanks!

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This does indeed sound tricky. I think you need to break the problem down some more to make any progress.

 

Is this a custom board? Is there external Flash?

 

What do you mean by hang? Is this while debugging? Is there a hard fault?

 

Why is changing the wait states not a satisfactory solution?

 

If you remove the flash_read_unique_id call all together does the problem go away? What about if you change it to occur at another time? Occur 100 times?

 

What do you mean by "FLASH address space seems to be temporarily relocated"? You mean the base address changes to access the unique id? That's no big deal and should be handled behind the scenes if you're using the ASF efc driver.

 

Can you strip everything out that doesn't affect the problem and get it to consistently fail on a test case? If so, post the test case.