Author Topic: CH32V003 SPI  (Read 608 times)

0 Members and 1 Guest are viewing this topic.

Offline SuecoTopic starter

  • Contributor
  • Posts: 12
  • Country: es
CH32V003 SPI
« on: February 24, 2024, 10:34:08 am »
Hi,

I've designed a CH32V003 based HMI that includes an LCD for an 3kW inverter. Being quite noisy, I2C wasn't performing at all so well, even though it was workable after some workarounds. To improve the reliability I switched to SPI, which ended up improving the error rate to almost nil with the inverter at full output power. Just to be on the safe side, I decided to perform basic signal integrity measurements to be sure that bus terminations and everything was working properly. The LCD controller AiP31068 datasheet showcases the use of SPI mode 3 (CPOL High, sampling on rising edge) when interfacing to it, but something's apparently wrong in the SPI implementation of the MCU for that particular mode, because to my astonishment there are data line edges on the rising edge of the clock signal on the word boundaries. Apparently  the BSY flag is cleared immediately when the last rising edge of the word is sent, then the DMA writes to the output data register and the output shift register writes the firs bit of the following word immediately to the output. Even though the system was working properly in lab conditions, these units will operate across a range of temperatures from -25ºC to +85ºC so it's quite uncertain would could have happened when propagation delays and edge detectors start to deviate from the nominal values with temperature. I ended up switching to SPI mode 0 (CPOL low, sampling on rising edge) which is accepted by the LCD controller, and doesn't exhibit these issues, however mode 1 (CPOL low, sampling on falling edge) also fails miserably, it's like the modes were implemented just adding a NOT gate somewhere.

As far as I know there's still no silicon errata for these chips, by best guess is this is one of several described by other people, which shouldn't surprise us given the price of the part. I've double and triple checked the reference manual and this is not the described behaviour, even though both reference manual and datasheet require a big dose of imagination to read. In mode 3 it's supposed that MOSI will remain unchanged up until well after the clock's last rising edge, I'd guess half a clock period would be ideal, but it looks like they've oversimplified the peripheral resulting in an unexpected and in my opinion unreliable behaviour. The measured delay between clock sampling and data switching state is 21ns (ie one 48MHz clock cycle), the admissible value listed in the LCD controller datasheet is anything greater than 10ns, which explains why it was working properly, however I'm not very comfortable with this. Am I being too strict here, or should we all avoid back to back word transmission in SPI modes 1 and 3 when using these MCUs? Obvoiously I don't expect a silicon revision for this issue in the near future.

This is the unexpected behaviour detected in mode 3:



With the SCLK to MOSI delay measured:



And reproduced in mode 1:



Best regards everyone
« Last Edit: February 24, 2024, 10:48:34 am by Sueco »
 

Offline DavidAlfa

  • Super Contributor
  • ***
  • Posts: 5912
  • Country: es
Re: CH32V003 SPI
« Reply #1 on: February 24, 2024, 12:20:06 pm »
The noise shouldn't be an issue unless you're driving the display remotely through long wires or the pcb layout is terrible.
The mcu board shoud be shielded to reduce EMI, and if using cables between the mcu and the display, they should be short and also properly shielded.
There're plenty of electrically conductive tapes for this task.
The I2C resistor pullups can be lowered to 1K or 470R for further noise resistance.
Hantek DSO2x1x            Drive        FAQ          DON'T BUY HANTEK! (Aka HALF-MADE)
Stm32 Soldering FW      Forum      Github      Donate
 

Offline SuecoTopic starter

  • Contributor
  • Posts: 12
  • Country: es
Re: CH32V003 SPI
« Reply #2 on: February 24, 2024, 01:02:10 pm »
Thanks DavidAlfa for your reply, however I think you've slightly missed the point of my post, even so I've reviewed your answer,

The noise shouldn't be an issue unless you're driving the display remotely through long wires or the pcb layout is terrible.

I2C suffers very much from noise and crosstalk unless you're running tracks shorter than 3 or 4 cm. The tracks have been ground warded, but the inverter switching 6 IGBTs from 0 to 340V in 700ns at 10 kHz injects noise from the switching frequency up to 30MHz. The I2C controller of the CH32V003 is very prone to locking up during the start condition, that combined with the LCD controller weakling driving SCL low, probably due to E field interference, which this controllers are generally very sensitive to, resulting in an interruption of the communications. We ended up having to reset the controller, take controls of SCL and SDA as GPIOs and force them to perform the recovery sequence for the controller (ie START-16 CLK pulses at SDA low-STOP) and reenabling the controller again each time the LCD was refreshed, and since there was no way to know if the data had been indeed received correctly, rewriting the LCD at a rate of 200 Hz so any eventual data corruption would last only 5ms and be unnoticeable. This worked well, but is far from ideal.

The mcu board shoud be shielded to reduce EMI, and if using cables between the mcu and the display, they should be short and also properly shielded.

We are using CH32V003 because we target a very low cost production cost, we don't have the budget for filtering chokes, much less shielding of any kind, only one SMD ferrite to minimise the worst of RF EMI. The system must be noise tolerant, not noise immune. The secondary problem when designing inverters is that the motor chassis and its power cabling shielding, which is required for compliance, are both connected to earth (I'll make a distinction here between earth and ground, since our controller ground voltage is referenced to mains, which earth is not). If we connect any kind of shielding to earth all the noise coming from both motor and power cable will be injected into the cable you're actually trying to protect. If wan't to try and use ground, can't be done because it's at mains potential. If you want to use the secondary double insulated ground, the flyback common mode safety capacitor leaks noise in the frequency of kHz, so you'd have to put in place proper common mode and differential filtering, which we can't afford. So shielding is a no go, even our incremental quadrature encoder, which has cable lengths of up to 25m and uses single ended signals (we can't affort differential transceivers here) has been designed to work reliably with no shielding in any possible environment.

There're plenty of electrically conductive tapes for this task.

Problem is copper is a no go also because this system is used in healthcare and food industry environments, and exposed copper reacts poorly with humidity, moreover there's ingress of disinfection chemicals and gasses with high corrosivity. There's also the problem that the assembly guys refuse to do anything more than the minimal required assembly tasks, they won't even install the compliance output ferrite in series with the motor power cable, so anything that requires extra work outside the engineering department is out of the question, on account of an excess of laziness.

The I2C resistor pullups can be lowered to 1K or 470R for further noise resistance.

I won't say that's always a mistake, but I'm quite certain that's always a mistake. I don't know how started that myth about I2C and lowering pull-up resistors. It's highly unlikely that your coupled noise equivalent output impedance is in the range of less than 1K unless you're running an insanely long I2C bus. Lower pull-up resistors were mandated by higher clock frequencies to overcome the capacitance of the bus tracks, but that has severe drawbacks, that results in larger rising edge slew rate, which most of the time results in higher crosstalk, it's true that the worst case scenario should be rising edge agains open collector pulled up line which shouldn't result in data corruption, but in reality, just with 5cm of unguarded tracks and 2.2K pull-ups I've been able to capture data flipping from 0 to 1 at the receiving side, so it's better to stick with the regular 4.7K resistors and either keep your buses short, slow and guarded, or if you can't avoid it because you need the speed and your capacitance is high, go no further down 2K and design your PCB with the utmost care including series resistors for every bus driver so that falling edges have controled slew rate, which is in fact one of the greatests noise sources on any I2C bus.

Best regards
« Last Edit: February 24, 2024, 01:05:14 pm by Sueco »
 

Offline DavidAlfa

  • Super Contributor
  • ***
  • Posts: 5912
  • Country: es
Re: CH32V003 SPI
« Reply #3 on: February 24, 2024, 05:55:13 pm »
This worked well, but is far from ideal
Minimal assembly tasks. Minimal costs.... Everything here is far from ideal.
Your company chose the cheapest path, lowest cost mcu, lowest cost everything, now deal with the consequences.  :-//
This sounds so familiar to me... you might work in the same company as I do!
They're just a bunch of lazy people earning the big money as "coffee" engineers. All they do is blahblah and take more coffee.

Why go so cheap? You have the STM32G030 series for 30-35 cents:
https://www.lcsc.com/product-detail/Microcontroller-Units-MCUs-MPUs-SOCs_STMicroelectronics-STM32G030F6P6TR_C529330.html

You should already know I2C isn't meant for extremely noisy environments like this. Neither SPI.
I would expect a 4-layer pcb with all digital signals sandwiched inside, heavily shielded by grounded planes.
The crosstalk you're talking about could very well be poor VDD decoupling, causing the switching noise to go everywhere.
I've seen (And fixed) 20KW UPS... they had a PIC inside, they had no fancy pcbs, lots of TH, long traces...
« Last Edit: February 24, 2024, 05:59:28 pm by DavidAlfa »
Hantek DSO2x1x            Drive        FAQ          DON'T BUY HANTEK! (Aka HALF-MADE)
Stm32 Soldering FW      Forum      Github      Donate
 

Offline SuecoTopic starter

  • Contributor
  • Posts: 12
  • Country: es
Re: CH32V003 SPI
« Reply #4 on: February 24, 2024, 06:50:44 pm »
Hi,

I completely agree with your statements, the first batch of HMIs work fine using I2C after the required firmware modifications, however let me point out that we switched to SPI just to improve the overall performance.

Why go so cheap? You have the STM32G030 series for 30-35 cents

That's because it's a saving enough to buy a brand new SMD over, that's very much required, after purchasing 5kpcs.

You should already know I2C isn't meant for extremely noisy environments like this. Neither SPI.
I would expect a 4-layer pcb with all digital signals sandwiched inside, heavily shielded by grounded planes.
The crosstalk you're talking about could very well be poor VDD decoupling, causing the switching noise to go everywhere.
I've seen (And fixed) 20KW UPS... they had a PIC inside, they had no fancy pcbs, lots of TH, long traces...

I have I2C eeproms in the inverter control card itself and encoder ICs for absolute position feedback with no unsurmountable problems. An early revision of the HMI using I2C based on a PIC16F18323, however the poor documentation of the CH32V003 makes it slightly more difficult to properly ascertain any possible lockups, however they seem related to the LCD controller. Obvioiusly the PCB is a 2 layer one. SPI is behaving much more robustly, with unnoticeable transmission errors, probably because the lines are driven properly. The crosstalk I was referring to is inherent to the weak high level driving of I2C, I've measured up to 1.5V of transient voltage drop on SDA when SCL is driven low when there isn't enough guarding between them. However I'm digressing myself, the main problem with CH32V003 is the poor implementation of SPI modes 1 and 3, that might result in unpredictable behaviour if it's not taken into account, I'd dare to say that I'd avoid using DMA in these modes at any rate with this particular MCU.

Best regards
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf