AM3352: Unwanted Signals on SPI line during power up

Will

Give you see the activity prior to external code being loaded, it would suggest that it's part of the boot process. A few questions:

1. is the observed SPI data the exact same for each boot? Can you post a screenshot? 
2. Are there any other connections to these signals?
3. What is you primary boot device? 
4. What are your sysboot[15:0] settings? 
5. Both chip selects are active? 

Thanks

--Paul 

1.     is the observed SPI data the exact same for each boot? Can you post a screenshot?

Attached a screenshot of the first CS assert after power-on. Asserts for about 2-3 ms.

No, the data differs on each boot. I have several full data dumps if you are interested. Sometimes the SPI analyzer collects over a hundred bytes per boot in these few milliseconds. They are mostly zero bytes, but many times there are long sequences of non-zero. Here are a few example bytes from the MOSI side (the analyzer captures seemingly random bytes on the output side also).

  Boot #2: 1.536224e-03, MOSI: 80 40 24 82 48 24 82 48 00 04 92 09 24 90 00 00 00 00 00 00

  Boot #5: 1.471072e-03, MOSI: 80 24 55 2A AA A5 50 82 4A 94 2A 52 80 90 90 90 92 49 24 92

2.     Are there any other connections to these signals?

There are 7 slaves on this SPI channel. There is a MAX3390EEUD level shifter between the bus and the ADS7953.

3.     What is you primary boot device?

MMC1

4.     What are your sysboot[15:0] settings?

Sysboot is 0x403C (0100000000111100b), MMC1, MMC0, UART0, USB0

FYI, lines are on the screen shot: 0 = CS, 1 = CLK, 2 = MISO, 3 = MOSI

Will

Thanks for the information.  

As you listed, the boot mode you have selected will attempt to boot, in order, from MMC1->MMC0->UART0->USB0.

None of the boot interface use pins A13, B13, or D12 in their boot process.  Even if there were used, the internal boot code would would have a repeatable signature after each reset as it attempts to boot from the external peripheral. 

Is it possible something else connected to the SPI lines is generating the signals? 

--Paul

No, there shouldn't be anything else generating signals.

Of the 7 devices on this particular SPI bus, only the ADS79XX is having problems. Also, if the ADS comes up correctly, it runs fine indefinitely. It seems that if there were bus noise or signal problems, we would be seeing issues with the other SPI devices and/or ADS issues at run time.

Other devices on the SPI1 bus would not be affected as they are using different CS signals and therefore do not respond to the activity. Can you confirm? 

If no boot media is installed, the processor will try booting from each peripheral in the boot sequence. The only pin you are using in the SPI1 interface, that is associated with a boot mode, is B17. However, Without code be loaded, B17 should never activate since SPI0 is not one of your selected boot peripherals.

Pins A13, B13, and D12 are all driven low during and after reset. 

Pin R6 is Hi-Z during reset and driven low after reset.

Pin B17 is Hi-Z during reset and driven high after reset.

All pins will be  in mode 7 (GPIO) after reset.

Here's a excerpt of datasheet table 4-2 which details this:

Is it possible another one of the boot peripherals is loading code? 

If you connect to the processor via JTAG with not boot media present, what are the contents of the padconf registers for each of the pins in the above table? 

Also, what is the frequency of the observed SPI clock? 

--Paul

Thanks for the detailed response.

Can you confirm (separate CS signals)?
Yes, each slave has its own chip select. The SPI bus is heavily utilized and all the devices on it coexist without issue. Even in the rare case where the ADC gives us these bad readings, we don't observe any issue with any SPI devices.

Is it possible another one of the boot peripherals is loading code?
No. Also, we are not using B17 - we briefly tried it as an alternate CS, but it didn't help.

If you connect to the processor via JTAG with not boot media present, what are the contents of the padconf registers for each of the pins in the above table?
This will take some time to set up.

Also, what is the frequency of the observed SPI clock?
The target clock is 1 MHz. I measured an arbitrary 1 word transfer at 1.022 MHz.

Thanks

Klair

There has to be something else going on here.  Even if it were a SPI boot, which we know it is not,  SPI would run at 48MHz to get the quickest boot speed.

I don't know what observability you have, but have you checked to see if any other signals are toggling? 

I assume B17 is normally isolated and unused when the CS is being driven by R6? If so, is it a steady state when not connected or toggling?

--Paul

Ah, I misunderstood your clock frequency question, I had bus integrity in mind...

The SPI clock at boot time is irregular. It doesn't appear to be set up as a clock, it appears to just to toggle arbitrarily. Basically the same with CS, MOSI, MISO - all seem to just be randomly moving and the datascope captures at least some of this activity as valid SPI words. We don't know for sure that the ADS accepts these packets, we just suspect that it could be the root cause.

I scoped B17 before choosing it as a test CS, and it was quiet. Yes, it's just a pin going out to a test point, no pulls, or any other signal conditioning

Thx

If B17 was quiet before connecting it as a CS (assuming R6 was disconnected), what changed to make it toggle/noisy?   The processor is in boot mode so, we know the processor is not the source.

Is this issue on one board or multiple boards? 

When the signals are probed with a scope (not LA) , are they noisy?  

If the signals between the ADC and the processor are isolated, which side sees the activity?

--Paul