Large jitter on angle in resolver and sincos mode

[bexander]

My conclusion is that the spikes indeed are very repetetive.
I get 7350 data points between first and eigth spike so (7350 / 12000) * 1000 / 7 = ~88 ms between spikes.
Or 9650 data points between first and 28th spike so (9650 / 4000) * 1000 / 27 = ~89 ms between spikes.
So is there anything done in the uC with a frequency of 11,3Hz or ~780 control loop cycles??

Also in sin plot the large amount of noise is due to the offset is not centered, positive values are closer to 2000 points and negative closer to 1900. Even though there is a calibration at startup. I guess the positive sin spikes also are limited by the 4096/2 bit limit.

Spikes in sin an cos might have some dependancy on amplitude of the base signal. For cos, signal is 265 and spikes +-65 and for sin signal is 1960 and spikes +-150. Can do more measurements on this if needed?

Can these spikes be in similarity with thoose seen on first injected ADC measurement or did they happen on every measurement? Unlikely though that they would happen so precisely timed.

EDIT: All spikes from first log look very similar as the two zoomed in. A major oscillation then calm and then oscillations again.

EDIT2: Maybe doing injected 6, 6, 7, 7 can help get calibration more precise during init.

[johu]

There is a 100ms task, the one that flashes the LED. Could that be it?

[bexander]

There is a 100ms task, the one that flashes the LED. Could that be it?

I don't know how precise the timing is in my results but 100ms is a bit of 88ms, but hey, if its easy to test then why not.

I'm thinking more in the idea of some sort of overflow in a timer or something. The exciter pin is set in 50MHz mode.
By chance 50MHz / (2^16*2^6) = ~11,9Hz. I'm thinking if the exciter pin is slightly of for one pulse or so... This is a very longshot...
Trying to find some more information what 50MHz really implies.

[bexander]

I think I have found the source of the spikes!!!

It wasn't the LED but it led me to it.
Look at this, blue is resolver exciter signal and red is the disturbing pin.

And now, blue is resolver feedback sine input (R31) and red is the disturbing pin.

And finally the timing between disturbance spikes.

This is measured at R85 which is the output of STM32 pin 56 or PB4. This pin is pulled up to 3,3V with a 10k resistor (R85).
Question now is what the SW is doing to create the disturbance and how can it be stoped.
I will try to find it in SW, please Johannes, have a look as well.

Sidenote, pin 55 or PB3 have a long trace in the PCB that ends up in nowhere?

EDIT:
Why is this signal disturbing one might ask. Well it is almost adjecent to the output pin for the resolver exciter signal. It's trace on the PCB also runs directly under the input pins of resolver feedback signals (sine and cos). Even the LED voltage is effected by this disturbance.

[johu]

Hmm, both PB3 and PB4 are JTAG pins, not used by software. Also looked around Ms100Task and besides the LED it doesn't do any IO.

Did you try removing the LED? You can also remove the wifi module to check. Are you sure the disturbance doesn't show up on the 3V3 rail?

[bexander]

The LED runs at 100ms. This signal I found runs at 102ms and is out of sync with the LED.
This is how I first found it. Blue is LED at STM side and red is resolver exciter output pin. Observe the variation in amplitude at 3ms after negative flank on LED.

A couple frames later. Observe the variation of amplitude on both signals before negative flank on LED.

It might be some other pin causing this but that is defintly the spike. It has the same shape and length as the spikes seen in angle.
I will probe around some more. Will look at 3,3V as well.

Edit: No never tried removing the pin as that signal is out of sync with the spikes.

[bexander]

Ok, now I have found it!
Yes, Johannes, you are right. It is comming from the 3,3V rail and yes, it is the WiFi-module that is the root cause!! Well spoted!!
I'm sorry, I tried to measure the 3,3V before but with the wrong settings on the oscilloscope I didn't find anything. With the right settings it's easy to spot.

I'm able to dampen the effect with a hefty input RC-filter for the WiFi module using 2,7ohm/1000uF. I can still see spikes in angle, but with a lot less amplitude.

Spikes now below +-1 degree.

However this might be a problem on all boards using the Olimex module?
I own 3pc of this module and I tested all three. Two of them are programmed with the interface and the last one is "empty" as delivered from Olimex. All three causes the ripple on the 3,3V power line.
Or do I have a bad 3,3V regulator?
I'm thinking otherwise it might be a good idea to have a separate 3,3V regulator for the WiFi-module.

[johu]

Ok, I checked the schematic of the Prius V3 control board at it might be the ESP is not sufficiently decoupled. I only see a 0.1uF cap and no inductance. On V3 mainboard I use a 10uH/10uF LC filter and like said I don't observe the issue there. RC filter is not so well suited as the resistor would drop too much voltage or the cap must be really big like in your case.

[Jack Bauer]

I'll certainly add that filtering to the next run of boards. That said I'm running motors here with that board design AND the V1d has 2 wifi modules.

[johu]

Maybe it also depends on the wifi situation? Or regulator tolerances, power supply load regulation stuff like that...

[bexander]

I'll certainly add that filtering to the next run of boards. That said I'm running motors here with that board design AND the V1d has 2 wifi modules.

Yes, that is also why I suspect that the 3,3V regulator on my board might not be 100%. I'll test swithcing it out when possible.
Damien, if you make a new run of boards, there is some room for improvement regarding routing in the PCB in the bottom right corner. If you wan't, I can send a more detailed description?

Maybe it also depends on the wifi situation? Or regulator tolerances, power supply load regulation stuff like that...

It's the same behavior with a module not loaded with SW so something in bootloader or similar.

Did a current measurement or more specific, measured the voltage drop over a 5,1ohm series resistor.
Programmed module

Unprogrammed module

Current increases 100% during spike, from ~80mA to ~160mA! Longer duration on programmed module.
The current might be a bit on the high side for the 3,3V regulator as it also supplied the STM32. 200mA max and 150mA continious for a sot23 (250mW/(5V-3,3V))=150mA.

I will test with a new regulator and also add a LC-filter. The RC-filter is what I had at home for the moment. It will be ok for now.

Johannes and Damien, thank you for your patience and help finding the cause of this matter!
The 6, 6, 7 injection was a bonus improvement even though not the cause or solution.

[johu]

Same here, thats how things improve.
No longer the 1117 regulator on board? That's capable of 800 mA

[Jack Bauer]

When I worked in industry even the simplest designs were subject to 3 and sometime 5 design reviews before even allowed out to beta. Here I rely on experience, luck and standing on the shoulders of others. Its almost a certainty that mistakes get through. Thank you for the hard work and patience involved in finding this bug.

[bexander]

According to schematic it's a XC6206P332MR regulator in a SOT23-3 capsule.
I will replace it with a MCP1700-3302E. That's what I could find locally. That regulator has slightly more current capability but should still be limited by power loss and thermal properties of the SOT23 capsule.

[bexander]

I recived the extra board from Damien yesterday. Thanks again!
I have looked at angle output while feeding in two constant voltages as before with my first board.
There are spikes but slightly lower amplitude.

I then measured the voltage at C43, that equal to pin 13 or VDDA, i.e. power and reference for the ADC. Same as on my first board.

The current pulse drawn by the esp8266 is ~1,3ms long which coresponds to a base frequency of 770Hz. This is a very low frequency to filter out.
The suggested LC-filter of 10uH and 10uF will have a break off frequency of 16kHz so will not help. My RC-filter with 2,7ohm and 1000uF breaks off at 60Hz so will dampen the signal a bit over 10dB.

I think the simplest and cheapes way is to use a separate 3,3V regulator to power the WiFi-module. This will be my next step to test.
It will also allow the use of a RC-filter before this regulator to avoid disturbing the 5V as well.
The voltage at VDDA should be rock steady to get the best accuracy out of the ADC.

[johu]

Yes I considered that earlier but found the 10uH/10uF filter sufficient by experiment. While the total disturbance is indeed 1.3ms the sharp edge is much shorter, like 0.1ms
I will check again on a V3 mainboard.

[bexander]

Yes, I agree, the sharp edges will be smoothened but I expect that there still will be a change in voltage, though slower. In the case of VDDA, there should not be any changes to voltage level.
I plan to test tomorrow with a separate 3,3V supply to find out what will happen.

[johu]

Yes thats a plan. I guess also the weaker SOT-23 regulator contributes to the problem as it's a bit undersized for the ESPs current draw.

[bexander]

Started by measuring 3,3V current draw (voltage drope over a 1ohm resistor) of the board excluding the WiFi-module.
Just below 120mA. So with the load of the WiFi-module the 3,3V regulator has to work hard.

So I patched in an separate 3,3V regulator to power the WiFi-module, and now the spikes are gone from the angle plot.

I also discovered another source of disturbance, the CAN tranceiver. When running the board alone the tranceiver sends out messages every 550us as it never receives reply. So when probeing C43, or VDDA, the result is 30mV pk-pk ripple. In normal case this will only be seen every 100ms (or 10ms) when messages are sent out.

This will also have a negative effect on all ADC measurements so I plan to swap out the present 3,3V CAN-tranceiver for a MCP2562-E/SN. This MCP tranceiver can be powered from 5V for all power requiring stuff and then has a separate I/O-supply that allows 3,3V to be used for the low current I/O (Rx, Tx pin). Will report back when this is tested but will take some time as I have to wait for component delivery.

I think it is a good idea, for all boards, to use a separate supply for the WiFi-module. It will be much harder to try to filter out this type of disturbance then to simply use on extra LDO and two ceramic capacitors(1uF input and 10uF output).

[mdrobnak]

This is an awesome thread, great job getting to the bottom of the issues!

Which designs would be affected by this? All of them?

-Matt

[bexander]

This is an awesome thread, great job getting to the bottom of the issues!

Which designs would be affected by this? All of them?

-Matt

All designs using the same source of 3,3V to supply STM32, WiFi-module and/or CAN will to some extent be affected. Note that even though there might be some disturbances present the board may still be working well.

[bexander]

Finally I have replaced the CAN-tranciver to a MCP2562-E/SN with 5V supply and I/O running at 3,3V

VDDA with old CAN tranciver.

VDDA with MCP2562.

Now I can't find any periodic disturbances on VDDA so I call this done.

[bexander]

Adding a picture of the CAN-transceiver mod of my board.

[johu]

Wow, thats actually rather surprising! So you go from 30mV or 1% jitter (assuming 3V resolver amplitude) to maybe 10mV or 0.3%. I mean either will work but it still looks better

[bexander]

In normal case the VDDA would make a dip and rise every 100ms when a CAN message is sent. When I run the board on the bench there is no reply on CAN and the transceiver repatedly sends messages causing the continious triangle wave.
This voltage dip on VDDA causes spikes in ADC measurements.
Now the dips caused by WiFi-moule and CAN transceiver are removed. I have not checked in car yet as I'm doing a bettery change as well as motor/inverter change so it takes some time before I can test resolver and current feedback for hopefully no spikes.

For future logic board designs it might be a good idea to consider using a 3,0V shunt voltage precision reference supplied from the 3,3V bus, to supply the VDDA. This will require HW adjustments on resolver signals (to keep the below 3,0V) and maybe current and voltage feedback as well but should give a solid supply to VDDA.