SAM9260-EK garbage on DBGU

[ekorren]

Hello!

I am trying to get something to boot from the evaluation kit. Regardless of what I get garbage on the serial debug port.

This is an example of the AT91bootstrap which should say

Code: Select all

RomBOOT
>

AT91Bootstrap ...

instead I get

Code: Select all

RomBOOT
>pH�>n���DT�9D�vGDdN0

Any ideas?

Best Regards
Ekorren

[ekorren]

Addendum:

I measured the baud rate and instead of being 115200 it is around 300000 (but the output is correct). I am trying to run unmodified examples on the evaluation kit just to get a baseline to work from. Any ideas as to why it seems the baud rate is much over the default one? Is there some setting on the board that I have missed? Incorrect clock setting?

BR

[blue_z]

I am trying to get something to boot from the evaluation kit. Regardless of what I get garbage on the serial debug port.

You have only stated a minimal description of the problem, and have provided no salient details or context.
By "regardless of what ...", is that supposed to mean that this board has never booted successfully?

If this board has previously booted successfully, then what are the circumstances that relate to this boot issue?

This is an example of the AT91bootstrap which should say

Code: Select all

RomBOOT
>

AT91Bootstrap ...

Your "example" does not appear to be authentic. I've never seen a line with a '>' character during a normal AT91 boot.

Regards

[ekorren]

As this is regarding an evaluation kit I would assume that fewer details would be necessary. I will attempt to add more, my mistake.

The EK it setup to a default configuration regarding jumpers and solder patches, just like it would be from the factory.

"Regardless of what" in this context is every example I find in terms of binaries on Microchips site relating to the board (https://www.microchip.com/DevelopmentTo ... SAM9260-EK). This includes an at91 recovery, WinCE demo and a few others. I do this to e.g. avoid using a non supported compiler version. However I do get the same symptom with a way to high baud rate (measured to around 300k) instead of the expected 115200 from the bootloaders.

I have never seen the board working in a way other than this. It was a second hand so it is possible that the chip is defect in some way.

As you might imagine I am looking for something very basic that I have missed. I am looking for a fail safe procedure to confirm that the board is in good shape.

The ‘>’ character belongs to the “RomBOOT” and is output at 115200.

I hope that clarifies a bit. Sorry for the lack of detail.

Regards

[blue_z]

I have never seen the board working in a way other than this. It was a second hand so it is possible that the chip is defect in some way.

Have you performed a thorough visual inspection of the board?
Depending on the workmanship (or lack of it), any board modifications could be detected.
Scrutinize the 18.432 MHz crystal that is for the embedded oscillator.

I am looking for a fail safe procedure to confirm that the board is in good shape.

Your doubts on the condition of this board is salient, and should have been mentioned.
Does your board have a Rev A or B part?

The ‘>’ character belongs to the “RomBOOT” and is output at 115200.

So it does.
I even forgot that I had previously wrote about it:

Older versions of RomBOOT (e.g. as in the AT91SAM9260) would always output the ">" on a new line after the "RomBOOT". That apparently has changed so that the prompt is only output if the Monitor is executed.

Regards

[ekorren]

Have you performed a thorough visual inspection of the board?
Depending on the workmanship (or lack of it), any board modifications could be detected.
Scrutinize the 18.432 MHz crystal that is for the embedded oscillator.

The board looks visually good. I cannot see any modifications.
The crystal measured to 18.43 MHz (I lack equipment for better precision).

Your doubts on the condition of this board is salient, and should have been mentioned.
Does your board have a Rev A or B part?

Sorry about not being more clear from the beginning.
The part is a rev A. That is my biggest suspect at the moment. It might sound like a long shot, but I assume I am throwing rev B code at it and it hits some rev A error causing the strange behaviour. Does this sound remotely possible? I will replace it for a rev B.

Regards

[blue_z]

The part is a rev A.

Actually I was hoping that you'd report that you had some kind of pre-production/engineering sample, and that there was a baudrate snafu like the SAMA5D2.

That is my biggest suspect at the moment. It might sound like a long shot, but I assume I am throwing rev B code at it and it hits some rev A error causing the strange behaviour. Does this sound remotely possible?

No, that's not likely.

I will replace it for a rev B.

Isn't it a BGA chip? Seems high risk.
If you're confident that the crystal and board power (there's like seven voltages to verify) are good, then I would try testing it with some software before trying something as risky as SoC replacement.
Try building AT91Bootstrap (i.e. test with software that you have control of), and verify all possible clock or timing related outputs, e.g. SDRAM timing. Tinker with the PLLA and baudrate settings.

Regards