CCS/TMDXRM46HDK: RM46 HDK has signal spikes when code has been initialized(run), but not present during download and before code run.

Hello,

Is the ring events caused by the board? Is there difference between the scope value and the ADC sampled value?

Still working on this. The 140mV and 70mV ringing spikes are apparent in every code change I have tried. Are there any settings in HalCoGen that I should try.
We do know that there are options to reduce board noise with added circuits. If we can silence the ring with HalCoGen configuration&code, that would be best.

Neil,

If the noise can be silenced via settings to Halcogen, it would be very unusual. i.e., if you can implement external cicuits to quite the noise, it means there are board level design considerations that were not implemented relative to board noise suppression and the only way it would be eliminated if coming from the MCU would be to quiet the MCU as far as I can see. Without board level changes (ferite beads, noise filtering, etc), how would you suppress the natural propagation of this noise through settings in the configuration of the MCU? Slow the clocks? reduce or eliminate switching noise on IO by turning off the IO? To even begin this, you would need to correlate the occurrence of the spikes to specific events in the MCU which is either going to be very apparrent due to the frequency of the spikes, or very difficult if the frequency doesn't correspond to any singular event or series of events.

I don't recall or see if you have been able to see if the noise spikes are truly coming at the pin level or if it is all internal to the device? i.e., is it only seen in the ADC counts and not necessarily on the incoming signal? If at the pin/signal level, do you see them when the MCU is powered by held in reset? Do you see them when in free run mode rather than when hooked up to debugger via emulator? Is there ethernet communications ongoing or CAN communication ongoing, SPI, UART, etc? Are you using ECLK to output a clock on the board? all of these can cause board level noise that could somehow find it's way to the input.

Another potential source that should be checked is if you are using the same 3.3V supply for Vccad and ADREFHI as for Vccio. this could cause IO noise to propagate to the ADC. To resolve this, you would need to disconnect from the board 3.3V rail for these pins and connect another external 3.3V supply. There should be either some zero ohm resistors or a jumper available to disconnect from the conventional supply and apply your own. I would have to look at the schematic to get more specific details.

Here are some of the answers to your questions:

When we placed a battery as the signal source, the spike/ring was still observed on the signal pin. That implies the spike/ring is not externally sourced (a battery being a solid source).
The spikes do appear in values input from the ADC.
The spikes have a 70mV swing which rings down when only group1 is configured and converted.
The spikes have a 140mV swing which rings down when both group1 and group2 are configured and converted.
The occurrence of the spikes is related to the Cycle Time as set in HalCoGen. It is possible that long cycle time settings have less dramatic ADC value impacts, and short cycle time settings show the spike as a more noticeable value change.
We are configuring both ADC1 and ADC2 with event triggers for software continuous operation using ID results.

The behavior is observed both when connected in debug or free run (and both debug build and release build).
We are configuring CAN1. The behavior does not change if we disconnect the CAN network.

You mention several features that might be a source. Can you point me to guides that would allow me to confirm/change those things to make sure they are not the source? (ETH, SPI, UART, ECLK,...).

I have a company request in to consider circuit changes to our test IO board (and HDK board if required); at the moment I am being asked to consider/eliminate this as a configuration problem.

Neil,

I recall on your other thread about this issue that you had some scope plots showing the glitching. Where were these measurements taken?

Also, it sounds like there is no correlation to any feature/function that relies on fast switching of the IO since CAN is the only IP used that would qualify for this. Correct me if I am wrong on this assumption. Since this is the case, no need to worry about the other IPs such as ethernet, uart, eclk, etc if you are not using them.

Given the correlation to the ADCG1 and G2 conversions compunded with use of the ADC1 and ADC2, I am wondering if there might be some connection with the errata ADC#1 in the errata document (www.ti.com/.../spnz200).

To test this, is it possible to try the conversion(s) on a channel(s) that is(are) not shared between ADC1 and ADC2 and only convert on ADC1? Alternatively, you could try to arrange your triggers so they are staggered and the sample windows for ADC1 and 2 do not overlap.

I would also recommend having a look at the ADC supply and reference voltages on the board as well. It is possible that they might be picking up some noise if the supply is shared with the board common 3.3V rail (flash, IO, OSCIN supply as well) so a lot of potential switching noise on this rail.

Sorry, Neil. I am not certain why the pasted link didn't work. It was a link copied directly off of the RM46L852 product page.

Try this one instead: www.ti.com/.../spnz200f.pdf

Note that this is the errata for the Rev.B silicon device which should be what is on your HDK. The latest silicon revision is Rec.C and this errata still applies.

I have tried removing ADC2 which eliminates errata ADC#1 as the culprit. Let me know if you think my assertion is correct on that.