AM3352: Wifi peripheral connected to MMC1 causes NAND boot to fail.

johan favorel

Part Number: AM3352

Hello,

We have an issue during a WARM reset. The board should boot from NAND, but it tries to boot from a Wifi peripheral that s connected to the MMC1 interface.

The MMC0 interface is connected to a SDcard connector and only used in production for initial programming of the on board nand flash.

Our sysboot (4:0) is set to 00100. This means UART0/XIP/MMC0/NAND.

So, in production it boots from MMC0 (SD card), and in the field it boots from NAND.

But once the Wifi slave (connected to MMC1) gets initialized, we have a issue at the next warm reset.

Since it is connected to MMC1, I would not expect any interference in the boot scheme. "00100" never addresses MMC1 as a boot device.

How can we block the attempt to boot from MMC1 ?

over 6 years ago

0 Brad Griffis over 6 years ago

TI__Guru*** 125430 points

Johan,

Please download this diagnostic script:

git.ti.com/.../am335x-boot.dss

After experiencing the failed warm boot, run the script by following the directions here:

git.ti.com/.../README

Please attach the text file output to this thread. It will hopefully provide some clues as to what's going wrong. In fact, I recommend running the same diagnostic after a good boot too. That will likely serve as a good point of comparison.

Best regards,
Brad

0 johan favorel over 6 years ago in reply to Brad Griffis

Prodigy 170 points

Hi Brad,

we are running a embedded linux. We are unfamiliar with running a java script on our platform. Can you inform how to install a DSS interpreter program on our platform.
Also, are you sure this tool can help to analyze a previous failed boot. Don't forget we need to power cycle to properly boot again. It would mean that debug info is kept in non volatile registers to be read out afterwards ?
regards

0 Brad Griffis over 6 years ago in reply to johan favorel

TI__Guru*** 125430 points

Please read the README file I pointed to. It explains that this is not something executed from embedded linux, but rather a script that runs in the Code Composer Studio scripting console.

Basically you will power up the board such that it is sitting there in a failed state. Then you will connect JTAG, run the script, and post the output to the forum.

0 johan favorel over 6 years ago in reply to Brad Griffis

Prodigy 170 points

Hello,

we will retrieve the logs as you requested. It will take a few days to do so.

But in parallel, could you try to find out why the boot sequence (not containing MMC1 in our case) is interrupted/blocked by a device on the MMC1 interface ? There are no common lines with the MMC0 interface, so I would expect no interference.

regards

0 johan favorel over 6 years ago in reply to johan favorel

Prodigy 170 points

Hello again,

See below and attached the log file from your script (taken at the moment of hanging)

When we tried to do the same when properly booted (linux kernel only), we had a emulator error:

CortxA8: Error connecting to the target: (Error -1170 @ 0x0) Unable to access the DAP. Reset the device, and retry the operation. If error persists, confirm configuration, power-cycle the board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 6.0.576.0)

LOG during HANG situation :

CONTROL: device_id = 0x2b94402e

* AM335x family

* Silicon Revision 2.1

PRM_DEVICE: PRM_RSTST = 0x00000001

* Bit 0 : GLOBAL_COLD_RST

CONTROL: control_status = 0x00410304

* SYSBOOT[15:14] = 01b (24 MHz)

* SYSBOOT[11:10] = 00b No GPMC CS0 addr/data muxing

* SYSBOOT[9] = 0 GPMC CS0 Ignore WAIT input

* SYSBOOT[8] = 1 GPMC CS0 16-bit data bus

* Device Type = General Purpose (GP)

* SYSBOOT[7:6] = 00b MII (EMAC boot modes only)

* SYSBOOT[5] = 0 CLKOUT1 disabled

* Boot Sequence : UART0 -> XIP w/WAIT (MUX1) -> MMC0 -> NAND

ROM: Current tracing vector, word 1 = 0x000090be

* Bit 1 : [General] Entered main function

* Bit 2 : [General] Running after the cold reset

* Bit 3 : [Boot] Main booting routine entered

* Bit 4 : [Memory Boot] Memory booting started

* Bit 5 : [Peripheral Boot] Peripheral booting started

* Bit 7 : [Boot] GP header found

* Bit 12 : [Peripheral Boot] Device initialized

* Bit 15 : [Peripheral Boot] Peripheral booting failed

ROM: Current tracing vector, word 2 = 0x00011000

* Bit 12 : [Memory Boot] Memory booting trial 0

* Bit 16 : [Memory Boot] Execute GP image

ROM: Current tracing vector, word 3 = 0x00010010

* Bit 4 : [Memory Boot] Reserved

* Bit 16 : Peripheral booting device UART0

ROM: Current copy of PRM_RSTST = 0x00000000

ROM: Cold reset tracing vector, word 1 = 0x00000000

ROM: Cold reset tracing vector, word 2 = 0x00000000

ROM: Cold reset tracing vector, word 3 = 0x00000001

* Bit 0 : [Memory Boot] Memory booting device NULL

Cortex A8 Program Counter = 0x00020080

ROM Exception Vectors

* 0x4030CE04 Undefined

* 0x4030CE08 SWI

* 0x4030CE0C Pre-fetch abort

* 0x4030CE10 Data abort

* 0x4030CE14 Unused

* 0x4030CE18 IRQ

* 0x4030CE1C FIQ

ROM Dead Loops

* 0x00020080 Undefined exception default handler

* 0x00020084 SWI exception default handler

* 0x00020088 Pre-fetch abort exception default handler

* 0x0002008C Data exception default handler

* 0x00020090 Unused exception default handler

* 0x00020094 IRQ exception default handler

* 0x00020098 FIQ exception default handler

* 0x0002009C Validation test PASS

* 0x000200A0 Validation test FAIL

* 0x000200A4 Reserved

* 0x000200A8 Image not executed or returned

* 0x000200AC Reserved

* 0x000200B0 Reserved

* 0x000200B4 Reserved

* 0x000200B8 Reserved

* 0x000200BC Reserved

Fullscreen locked startup log.txt Download

CONTROL: device_id = 0x2b94402e
  * AM335x family
  * Silicon Revision 2.1

PRM_DEVICE: PRM_RSTST = 0x00000001
  * Bit 0 : GLOBAL_COLD_RST

CONTROL: control_status = 0x00410304
  * SYSBOOT[15:14] = 01b (24 MHz)
  * SYSBOOT[11:10] = 00b No GPMC CS0 addr/data muxing
  * SYSBOOT[9] = 0 GPMC CS0 Ignore WAIT input
  * SYSBOOT[8] = 1 GPMC CS0 16-bit data bus
  * Device Type = General Purpose (GP)
  * SYSBOOT[7:6] = 00b MII (EMAC boot modes only)
  * SYSBOOT[5] = 0 CLKOUT1 disabled
  * Boot Sequence : UART0 -> XIP w/WAIT (MUX1) -> MMC0 -> NAND

ROM: Current tracing vector, word 1 = 0x000090be
  * Bit 1  : [General] Entered main function
  * Bit 2  : [General] Running after the cold reset
  * Bit 3  : [Boot] Main booting routine entered
  * Bit 4  : [Memory Boot] Memory booting started
  * Bit 5  : [Peripheral Boot] Peripheral booting started
  * Bit 7  : [Boot] GP header found
  * Bit 12 : [Peripheral Boot] Device initialized
  * Bit 15 : [Peripheral Boot] Peripheral booting failed

ROM: Current tracing vector, word 2 = 0x00011000
  * Bit 12 : [Memory Boot] Memory booting trial 0
  * Bit 16 : [Memory Boot] Execute GP image

ROM: Current tracing vector, word 3 = 0x00010010
  * Bit 4  : [Memory Boot] Reserved
  * Bit 16 : Peripheral booting device UART0

ROM: Current copy of PRM_RSTST = 0x00000000

ROM: Cold reset tracing vector, word 1 = 0x00000000

ROM: Cold reset tracing vector, word 2 = 0x00000000

ROM: Cold reset tracing vector, word 3 = 0x00000001
  * Bit 0  : [Memory Boot] Memory booting device NULL

Cortex A8 Program Counter = 0x00020080

ROM Exception Vectors
  * 0x4030CE04 Undefined
  * 0x4030CE08 SWI
  * 0x4030CE0C Pre-fetch abort
  * 0x4030CE10 Data abort
  * 0x4030CE14 Unused
  * 0x4030CE18 IRQ
  * 0x4030CE1C FIQ

ROM Dead Loops
  * 0x00020080 Undefined exception default handler
  * 0x00020084 SWI exception default handler
  * 0x00020088 Pre-fetch abort exception default handler
  * 0x0002008C Data exception default handler
  * 0x00020090 Unused exception default handler
  * 0x00020094 IRQ exception default handler
  * 0x00020098 FIQ exception default handler
  * 0x0002009C Validation test PASS
  * 0x000200A0 Validation test FAIL
  * 0x000200A4 Reserved
  * 0x000200A8 Image not executed or returned
  * 0x000200AC Reserved
  * 0x000200B0 Reserved
  * 0x000200B4 Reserved
  * 0x000200B8 Reserved
  * 0x000200BC Reserved

0 Brad Griffis over 6 years ago in reply to johan favorel

TI__Guru*** 125430 points

Which pins are being used for your MMC1 connection of the WiFi device? There are multiple mux options.

0 Brad Griffis over 6 years ago in reply to Brad Griffis

TI__Guru*** 125430 points

I'm traveling this week so my responses might be delayed. Your dump from the earlier post showed the XIP mode being used (i.e. that uses the GPMC pins). I'm wondering if because the GPMC is muxed with MMC1 that it is "fooling" the boot ROM into thinking it can actually boot from GPMC.

Also, I'd like you to try getting a capture of the boot script after Linux boots one more time. Try running this command from the Linux command prompt before running the script:

devmem2 0x44e00414 w 0x12500002

Or alternatively, hit a key during u-boot during the successful boot and then run the CCS script while u-boot is operational.

0 johan favorel over 6 years ago in reply to Brad Griffis

Prodigy 170 points

Hello,

The CPU package is ZCE.

The MMC1 pins being used :

MMC1.DAT[0:3] : GPMC_AD[8:11]

MMC1.CLK : GPMC_CSn1

MMC1.CMD : GPMC_CSn2

We will try to take a log, based on your extra info you just provided. (earliest this wednesday)

We also might try a sysboot combination without XIP to check your assumption (attempting to boot as XIP device)

0 johan favorel over 6 years ago in reply to johan favorel

Prodigy 170 points

Hello Brad,

We did some additional tests by changing the sysboot startup combinations.

Original : 00100 : UART0 / XIP / MMC0 / NAND.
Giving us the reboot problem as described.
Combination2 : 00110 : EMAC1 / SPI0 / NAND / NANDI2C
Giving us the same reboot problems as the original. Although we noticed 1 succesfull reboot. But we where not able to repeat this. So reboot failure remains.
Combination3 : 01100 : USB0 / NAND / XIP / NANDI2C
This combination gives ALWAYS a good reboot.

So, since combination2 is not working, it seems the bootprocess also gets stuck on EMAC1 or on SPI0.
Combination3 seems to solve the problem, BUT we will have to use a different combination in production (since we boot from MMC0 the first time). This is asking for modifications on the target board.
More, the units in the field or already produced can not easily be modified to COMBINATION3.

Do you have any other ideas for existing boards ?

regards

0 Brad Griffis over 6 years ago in reply to johan favorel

TI__Guru*** 125430 points

In your production line the test fixture can override one or more of the boot pins in order to force the necessary boot mode.

The only potential work around that comes to mind would be if you put the Wi-Fi back into a reset state prior to rebooting your board.

0 johan favorel over 6 years ago in reply to Brad Griffis

Prodigy 170 points

Hello Brad,
Do you have a root cause why the AM3352 tries to boot from XIP ? What does the chip have to see on the GPMC datalines in order to think it can boot from it ?

0 Brad Griffis over 6 years ago in reply to johan favorel

TI__Guru*** 125430 points

Anything other than 0xFFFFFFF or 0 is considered valid. I see you have sysboot8 tied high which indicates a 16-bit data bus for GPMC bootmodes. If you tie it low instead it will only use 8 bits which likely will avoid the issue.

0 Brad Griffis over 6 years ago in reply to Brad Griffis

TI__Guru*** 125430 points

To follow onto the last post, I think these pins are causing your issue:

MMC1.DAT[0:3] : GPMC_AD[8:11]

Switching to 8-bit data for GPMC would avoid that issue.

0 johan favorel over 6 years ago in reply to Brad Griffis

Prodigy 170 points

I tried by simply pulling down SYSBOOT-8 to indicate 8 bit XIP. And indeed the reboot process works fine now. So your theory is correct. Nevertheless, it asks for a manual patch on the existing boards since there is no footprint for such a pull down.
But this is going to be the final solution on longer term.
Thanks a lot for your support !
Johan

0 Brad Griffis over 6 years ago in reply to johan favorel

TI__Guru*** 125430 points

Ok, I'm glad the behavior is now understood. Perhaps disabling/resetting wifi prior to reboot is possible for the boards already in the field. The intent would be for those MMC1 data pins to be in the same state as they are during a cold boot. I expect resetting the wifi should accomplish that.

0 johan favorel over 6 years ago in reply to Brad Griffis

Prodigy 170 points

In case of a sudden watchdog reboot (due to a kernel panic or sudden crash), there is no time to disable the wifi in advance.
Also the Hardware reset line of the Wifi module is connected to a GPIO line of the sitara, so this is not an option either. Connecting the Wifi reset input to the system reset (RESETIN_OUT line) asks for a HW change as well. So, boards in the field will stay vulnerable.

0 johan favorel over 6 years ago in reply to johan favorel

Prodigy 170 points

Hello,

as an intermediate solution (until we do a board respin), I am wandering whether it would be reliable to just remove the pullup on the SYSBOOT 8 line. I know that it is not recommended to leave the sysboot lines open, but I did some measurements, and I calculate a internal pull down resistor of aprox 540KOhm. This is the case during and immmediately after POR.

Do you see an issue to leave this line open (and calculating on the internal pull down) to use this as a temporary solution ?

thanks for your reply.

0 Brad Griffis over 6 years ago in reply to johan favorel

TI__Guru*** 125430 points

My recommendation is to pull it down. You will need to weigh the effort of more intrusive board modifications with the potential issues caused if there are occasional issues.

Processors

Processors forum

AM3352: Wifi peripheral connected to MMC1 causes NAND boot to fail.