Problem with ATSAME70Q21 on custom board

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

Hi,

First off: I am a SAM newbee so there may be very something fundamental i have missed.

 

I am trying to get the uC on a custom board to do something basic like switch gpio, but the program does not reach the first breakpoints on the most basic sw for some unknown reason

If i pause the uC and step around in the disassembly that pops up the cpu is running code from 204000F2-20400324 in a continues loop, so i am guessing it is waiting/checking something before it will start main()

 

About the software:
I have tried various minimal sw from atmel studio, but the result it the same

New project->GCC C executable Project->Select ATSAME70Q21->Press Alt+f5 (Start debugging and break)
Programming settings is set to boot from flash

The loading of the software into the uC is done without any error/warnings, but after that the program does not get to the first breakpoint :(

About the board:

The board does not have any external flash/ram
The 3.3v power looks stable using a scope

It has an external crystall
 

About the debugger setup

A am using atmel studio 7, connected to the board using atmel-ice using SWD

Using swd i can read device signature and other information without any problems, so i think that part is okay.

 

 

Any help will be appropriated.
Not sure what information is needed so just shout out if something is missing

This topic has a solution.
Last Edited: Fri. Oct 23, 2020 - 07:44 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

larsES wrote:
I am a SAM newbee

Do you have experience with any other microcontroller(s) ?

 

larsES wrote:
I am trying to get the uC on a custom board

As a newbie, I would strongly recommend that you don't leap straight into a custom board - that gives you too many unknowns all at once.

 

Make life easier for yourself, and start with the Dev Board:

 

https://www.microchip.com/Develo...

 

That way you have known-good, documented and supported hardware to get started on.

 

Once you've gained sufficient familiarity with the product and the tools, then is the time to move on to custom hardware ...

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for the reply

awneil wrote:

Do you have experience with any other microcontroller(s) ?


Yes, 10+ years with avr (atMega128 variants)

 

awneil wrote:

As a newbie, I would strongly recommend that you don't leap straight into a custom board - that gives you too many unknowns all at once.

I did not, got a ATSAMV71-XULT and played around with it.
Got can, uart, timers, and gpio working on the dev board

 

awneil wrote:

Once you've gained sufficient familiarity with the product and the tools, then is the time to move on to custom hardware ...

And that was where i thought i was, but my knowledge will most likely have some big holessmiley

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

larsES wrote:
atMega128 variants

from that to a Cortex-M7 with 2MB of flash at 300MHz is a massive leap!

 

 

got a ATSAMV71-XULT and played around with it.
Got can, uart, timers, and gpio working on the dev board

So you should be able to take a simple, working blinky from  dev board and adapt it to your custom board.

 

If possible, have a blinky that will work directly on both the dev kit and your custom board - then you can compare it working on the dev board with whatever happens on the custom board; and you know the settings are all OK ...

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awneil wrote:
from that to a Cortex-M7 with 2MB of flash at 300MHz is a massive leap!

That is so true.

Its more capable, but it is also require more code to get stuff setup.

 

awneil wrote:
So you should be able to take a simple, working blinky from  dev board and adapt it to your custom board.

That is was i thought, but the code does not even reach main() sad

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

So you do have a simple LED blink working on the dev board ?

 

And you are familiar with using the debugger to step through that ?

 

And you have taken that exact same code, and loaded it onto your custom board ?

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awneil wrote:
So you do have a simple LED blink working on the dev board ?

Yes

 

awneil wrote:
And you are familiar with using the debugger to step through that ?

Yes, I know how to use basic ide debugging like breakpoint,stepping, watchwindows, i/o view

 

awneil wrote:
And you have taken that exact same code, and loaded it onto your custom board ?

Not the blinky code, but the minimal project that atmel studio generates for you.

That i have test om both boards

 

It stops there in the dev board, but not in the custom board

 

#include "sam.h"

int main(void)
{
    SystemInit(); //breakpoint here

    while (1)
    {
    }
}

 

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

larsES wrote:
Not the blinky code

So do it with the blinky code - so you have a direct comparison

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 2

If your crystal/oscillator setup on your pcb is not the same as on the dev board, then you'll get something like a hard fault exception before you get to main(). If you can debug, you should be able to trace execution through the startup code.

 

Other possibilities is your pcb design - component choice and pcb layout are critical. The pcb design is an active part of the circuit - not simply an interconnect. The processor will randomly fail if you get this part wrong.

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

Kartman wrote:
something like a hard fault exception before you get to main().

+1

 

You do have a Hard Fault handler, don't you?

You should be able to see the code reaching it ...

 

If you can debug, you should be able to trace execution through the startup code.

By default, Atmel Studio will run the startup code and halt on entry to main()

 

There is an option to have it start right at the beginning of the startup code - you will need this!

 

Again, practice on the Dev Board.

 

 

component choice and pcb layout are critical. The pcb design is an active part of the circuit - not simply an interconnect. The processor will randomly fail if you get this part wrong.

Especially for an advanced, high-speed chip like this - things you might have "got away with" on a simple, (relatively) slow AVR will come back to bite you!

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

First off, thanks for all the help and suggestions

 

Kartman wrote:
If your crystal/oscillator setup on your pcb is not the same as on the dev board

It is not the same.

 

Kartman wrote:
Other possibilities is your pcb design - component choice and pcb layout are critical. The pcb design is an active part of the circuit - not simply an interconnect. The processor will randomly fail if you get this part wrong.

That is true, it does not feel/look like it is randomly failing, but it is a possibility.

 

awneil wrote:

Kartman wrote:

something like a hard fault exception before you get to main().

+1

 

You do have a Hard Fault handler, don't you?

Ehh, nope.

I will make one and check it out

 

That sounds like the problem i am having.

I can see that the cpu is running and stuck in a loop doing something before main, but i do not know what it as does... my assembly is not that good
 

Last Edited: Tue. Oct 20, 2020 - 10:07 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:

If your crystal/oscillator setup on your pcb is not the same as on the dev board

larsES wrote:
It is not the same.

 

Start by making a blinky that works on the dev board using the internal oscillator.

 

Then put that onto your custom board - thus taking your external crustal stuff out of the question.

 

 

Quote:
I can see that the cpu is running and stuck in a loop

That's typically what you get for a default handler ...

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,

Thanks for all the help, the source of the problem has been fixed.

 

A am not definitely sure about the detail on the board, but was related to PB12 that also functions as a chip-erase.

When that pin was wired to 0v and after a power reset, the problem was gone.

 

When the chip erase was high the cpu booted into the rom bootloader, and from there it did not go to my main()

Even after the chip erase was set to low and fuse bit was set to boot from flash it still needed a power-reset to boot to main

 

 

Thanks again for all the help