SAMA5D27 (SOM1) initial config problem

Discussion around products based on ARM Cortex-A5 core.

Moderator: nferre

vholy
Posts: 3
Joined: Wed Sep 18, 2019 3:48 pm

SAMA5D27 (SOM1) initial config problem

Thu Sep 19, 2019 8:25 am

A couple of weeks ago we selected chip SAMA5D27 as a main processor for our product. For prototyping we are using SOM1 modules. However during testing we discovered that behaviour of 4 chips is not consistent. The modules with serial numbers 0021631 and 0021629 behave during initial communication correctly - we can read and send the data trough SAM-BA tool over the serial port or USB. But modules with serial numbers 0018378 and 0018385 behave total differently - we can only read ROOMBoot message on serial port in a terminal window. The USB enumeration ends in every case with error: "unable to enumerate USB device". In serial sniffer output it is seen two strings from SAM-BA, but none answer from chip. We checked signals direct on SOM pins - SAM-BA initial message is there, answer is missing, there is only the ROOMBoot message during cca 30sec. We are using for all 4 chips the same initial procedure, so the outcome has to be the same, but unfortunatelly is not.

To be able to continue our prototyping with Microchip products we need help. Please have anyone here any advise how to overcome this problem?

(Our enviroment is Linux Debian 10 and SAM-BA 3.2.1)

Thank you for your tips.

Regards
blue_z
Location: USA
Posts: 2007
Joined: Thu Apr 19, 2007 10:15 pm

Re: SAMA5D27 (SOM1) initial config problem

Fri Sep 20, 2019 1:06 am

vholy wrote: Please have anyone here any advise how to overcome this problem?
Start with accurate reporting.
Or are you actually "read[ing] ROOMBoot message on serial port in a terminal window"?

You have a peculiar way of describing the issue, i.e. primarily in terms of comparison:
"initial config problem"
"behaviour of 4 chips is not consistent"
"behave total differently"
"outcome has to be the same, but unfortunatelly is not".

More simply, two modules seem to respond as you expect and two other modules do not respond at all to any input.

You neglect to mention if there is a common carrier/baseboard (for power and interface connections) to initialize each module, or whether each module has its own carrier.
You neglect to mention if you've performed any visual and/or electrical checks on the SoMs.

Since you neglect to mention what this "initial config" procedure is, the test procedure can be reduced to a basic test to see if the SoM will respond to a simple query.
1. While powered off, also disconnect the SoM from VDBBU (to reset the BSCR).
2. Setup a terminal emulation program (e.g. minicom) connected to the DBGU port (e.g. UART1 using IOSet 1 on PD2 & PD3.
3. Power up the SoM, and expect to receive "RomBOOT".
4. Type "V#", and expect version information in response. Study the SAM-BA Monitor section in the SoC datasheet for background information.

Note that if you have managed to install an ARM Exception Vector in the QSPI flash and/or blown salient configuration fuses, then the SAM-BA monitor will not execute on the ARM processor.

Regards
vholy
Posts: 3
Joined: Wed Sep 18, 2019 3:48 pm

Re: SAMA5D27 (SOM1) initial config problem

Fri Sep 20, 2019 4:04 pm

Thank you for quick response. Answers to your questions are below.
blue_z wrote:
Fri Sep 20, 2019 1:06 am
You neglect to mention if there is a common carrier/baseboard (for power and interface connections) to initialize each module, or whether each module has its own carrier.
Each module is soldered on separate baseboard. During config phase are baseboards powered from lab power supply.

You neglect to mention if you've performed any visual and/or electrical checks on the SoMs.
all boards was checked many times with many persons. result the same: mechanically and electrically all ok.
Since you neglect to mention what this "initial config" procedure is, the test procedure can be reduced to a basic test to see if the SoM will respond to a simple query.
Basically it is qspi-flash programming and fuse programming. All is done via serial port. But when chip does not respond, programming is not possible - it is our mentioned initial config
1. While powered off, also disconnect the SoM from VDBBU (to reset the BSCR).
Our design does not use backup voltage, all Vdd pins are connected to one power supply. If Vdd is switched off, then all CPU is without power - BSCR is reset to default value.
2. Setup a terminal emulation program (e.g. minicom) connected to the DBGU port (e.g. UART1 using IOSet 1 on PD2 & PD3.
Yes, IOSET is correct and minicom is our prefered terminal emulator.
3. Power up the SoM, and expect to receive "RomBOOT".
Yes, all chips send this message - cca once per 30sec.
4. Type "V#", and expect version information in response. Study the SAM-BA Monitor section in the SoC datasheet for background information.
Only two chips return "v1.3 Oct 28 2016 16:04:43". Two other are silent. We are sure, that signal from our laptop are on pins of modul. This was many times checked with digital osciloscope. This not problem our knowledge of SAM-BA, this is problem with chips.
Note that if you have managed to install an ARM Exception Vector in the QSPI flash and/or blown salient configuration fuses, then the SAM-BA monitor will not execute on the ARM processor.
Nope, all chips was freshly soldered. Nobody before us has not chance manipulate with chips.

Regards
blue_z
Location: USA
Posts: 2007
Joined: Thu Apr 19, 2007 10:15 pm

Re: SAMA5D27 (SOM1) initial config problem

Sat Sep 21, 2019 2:52 am

vholy wrote: Each module is soldered on separate baseboard.
So the real problem involves two module+carrier assemblies rather than just two SoMs.

vholy wrote:
3. Power up the SoM, and expect to receive "RomBOOT".
Yes, all chips send this message - cca once per 30sec.
I was about to flag this as unlikely behavior until I was able to almost replicate this reboot cycle.

The typical Atmel/Microchip SoC will loop forever in the SAM-BA monitor after the RomBOOT message is output and no (external) memory device is found with a suitable boot program.
This is also explicitly stated in the SAMA5D2 datasheet in section 16.6, SAM-BA Monitor.
However my testing indicates that the SAMA5D2 behaves a bit differently than other SAM9 and SAMA5 SoCs.

When the device is powered up and only the DBGU has a connection to a host PC, a SAMA5D27CN (or CU) will restart (as indicated by the "RomBOOT" message) after about 15 (on one board) to 17 (on another board) seconds if the serial input stays idle.
However if the SAMA5D27 receives at least one character, then the SoC seems to wait forever for more input and no reboot occurs.
The SoC does respond to SAM-BA monitor commands in this situation.

I suspect that the watchdog timer may be involved in this reboot cycle, but I'm not able to confirm that.
The maximum watchdog period is about 16 seconds using a slow clock around 32 kHz.

When the device is powered up and there is both a USB and a DBGU connection to a host PC, the SAMA5D27 is stable after the initial "RomBOOT" message is output on the serial port, and no reboots occur.
The SoC seems to wait forever for any command input from the USB gadget (i.e. /dev/ttyACM0 on the PC host), and ignores all input from the serial port.

Note that I'm only testing with the ls and minicom commands on the PC host. No SAM-BA utility is involved so that the interactions with the SoC are well known.

The symptoms you report are a mixture of what I've described. Based on your previous inaccurate reporting, I can't determine if any of this applies to your suspect module+carrier assemblies.

Regards
vholy
Posts: 3
Joined: Wed Sep 18, 2019 3:48 pm

Re: SAMA5D27 (SOM1) initial config problem

Tue Sep 24, 2019 1:10 pm

blue_z wrote:
Sat Sep 21, 2019 2:52 am
vholy wrote: Each module is soldered on separate baseboard.
So the real problem involves two module+carrier assemblies rather than just two SoMs.
We tested all wrong modules in one specific carrier which previously hosted a good module. Result was the same. Modules did'nt answer to any sentence from SAM-BA. In minicom we tested version query "V#" without any answer. Good module returns string "v1.3 Oct 28 2016 16:04:43".

blue_z wrote:
Sat Sep 21, 2019 2:52 am
The typical Atmel/Microchip SoC will loop forever in the SAM-BA monitor after the RomBOOT message is output and no (external) memory device is found with a suitable boot program.
This is also explicitly stated in the SAMA5D2 datasheet in section 16.6, SAM-BA Monitor.
However my testing indicates that the SAMA5D2 behaves a bit differently than other SAM9 and SAMA5 SoCs.
Our chips were buyed direct from Mouser distribution. We assume the on-module QSPI memory was empty. Our assumption is supported by the fact that RomBOOT is running after each power on.
blue_z wrote:
Sat Sep 21, 2019 2:52 am
When the device is powered up and only the DBGU has a connection to a host PC, a SAMA5D27CN (or CU) will restart (as indicated by the "RomBOOT" message) after about 15 (on one board) to 17 (on another board) seconds if the serial input stays idle.
However if the SAMA5D27 receives at least one character, then the SoC seems to wait forever for more input and no reboot occurs.
The SoC does respond to SAM-BA monitor commands in this situation.
May be what you wrote could be linked with other revision of chips. Our good chips respond in any case.

blue_z wrote:
Sat Sep 21, 2019 2:52 am
When the device is powered up and there is both a USB and a DBGU connection to a host PC, the SAMA5D27 is stable after the initial "RomBOOT" message is output on the serial port, and no reboots occur.
The SoC seems to wait forever for any command input from the USB gadget (i.e. /dev/ttyACM0 on the PC host), and ignores all input from the serial port.
Correct. When chip provides USB enumeration to linux host then UART is quiet. But wrong chips never finalized USB enumeration, kernel returns error: "unable to enumerate USB device". USB guest (our chip) does'nt accept the address offered by kernel. Operation is repeated many times and ends with timeout.
blue_z wrote:
Sat Sep 21, 2019 2:52 am
The symptoms you report are a mixture of what I've described. Based on your previous inaccurate reporting, I can't determine if any of this applies to your suspect module+carrier assemblies.
No idea how to solve this problem. We will propably switch to other chip producer but we lost a lot of time dealing with Microchip...

Thank you a lot for your time and effort. If you will be in Europe just get in touch with us. We can meet and drink a good beer :-)
blue_z
Location: USA
Posts: 2007
Joined: Thu Apr 19, 2007 10:15 pm

Re: SAMA5D27 (SOM1) initial config problem

Wed Sep 25, 2019 1:07 am

vholy wrote: We assume the on-module QSPI memory was empty.
That is normally a reasonable assumption.
vholy wrote: Our assumption is supported by the fact that RomBOOT is running after each power on.
No, that is illogical.
The ROM program executes before any external memory is ever probed, so the "RomBOOT" message only indicates that the ARM processor has restarted.
You need to study the SoC datasheet that clearly spells this out.

To test if code from QSPI flash is being executed, then try connecting a JTAG probe, or use a 'scope or logic analyser to detect activity by that flash chip.

As a last resort you could try contacting Microchip Technical Support.

Regards

Return to “SAMA5D Cortex-A5 MPU”

Who is online

Users browsing this forum: No registered users and 1 guest