MSPM0L2228: SPI master receive not working for clock > 2MHz

Hi Robert, 

Interesting behavior. 1MHz SCLK can work and a higher frequency will cause receive data corrupted. Can you share the sysconfig file here, we can start to look into the configurations first. 

Best regards,

Cash Hao

Hi Cash,

Unfortunately I don't use syscfig for this project. I have designed my own support library.... sorry, I never like SysConfig. The purpose of SysConfig is to make life easier but it also makes things difficult to maintain from the viewpoint of source code.

The SPI read operation is very simple, it sends out 0xFF and wait for RXFIFO to be "NOT EMPTY" and then read the data. Interrupt and DMA are not involved. Here is the register dump for SPI0.

This is for 1MHz:

And this is for 8MHz:

Robert.

Hi,

These register value looks fine to me. Just one thing noticed, that the SPI0_STAT is always 0xF which means the SPI bus is busy. One thought is that I would suggest to use a receive interrupt to get the receive signal. I do not recommend to directly read from RXFIFO when it is "NOT EMPTY". 

Best regards,

Cash Hao

Hi,

SPI_STAT.BUSY is at the 5th bit. So, SPI bus is idle when STAT is 0x0F.

For high speed SPI, interrupt can't be used. If SPI_SCLK is 16MHz then there are only a few instruction cycles to read each byte. Interrupt latency is just too long for this. In fact, to test if the timing to read RXFIFO is too fast, some delay cycles are inserted before reading RXFIFO. Nothing different.

I have also implemented DMA to access FIFO. But there is something wrong with the code and I need more time to identify the issue.

The most strange thing is... the pre-production version (XMSPM0L2228) has no issue with 16MHz.

Robert.

Hi,

I thing the DMA to move data from RX FIFO will be a solution. And I thing we have related demo projects in SDK.(mspm0_sdk_2_03_00_07\examples\nortos\LP_MSPM0L2228\driverlib\spi_controller_repeated_fifo_dma_interrupts) You can refer to this demo code for test. 

I also want to check on your clock system configuration. What is your clock source for MCLK? Is it source from SYSOSC directly?

Best regards,

Cash Hao

Hi,

I have completed the SPI driver using DMA. Unfortunately, the situation is the same. 1MHz is working well but it failed for higher frequencies. The clock source for MCLK is SYSOSC (32MHz).

Btw, I also tested "delayed sampling value" 0, 1 and 2. No difference. "2" will make things worse.

I would like to mention another issue. I don't know if it is related. The LFSS RTC is very unstable in my test. I soldered 3 pcs of this PCB boards.

* For the 1st PCB, RTC is working well. I also implemented temperature compensation. For every minute, I read the MCU's temperature to calculate the PPM for compensation (LFSS_TCMP).

* For the 2nd PCB, RTCTCRDY is never set. If I set TCMP directly, it has no effect. And the RTC data (year, month, day, hour, min, sec) are not counting stably. Random numbers are observed in year and second registers. For example, I set year to 2025. But it will show 2017 and then auto change to other number later.

* For the 3rd PCB, it is the worst. LFSS_CLKCTL.MODCLKEN can't be set. I set it to 1, but it still shows 0. The RTC is not working at all.

To find out the cause, I exchanged the LFXT crystals between these boards. I also re-soldered MCU with a new one. No difference. The LFCLK is output to CLK_OUT for verification. It is 32767.1Hz (with two external 10pF load capacitors). The clock waveform looks stable.

I don't use LFSS tamper mode for this project. But SPI0 pinouts are related to TI0, TI1, TI2. There might be a silicon bug in LFSS which cause SPI_SOMI pin failed to run at high frequency.

My SPI driver is also used in MSPM0G3507 for other projects. They are working well for accessing NOR flash memory. So, I don't think the SPI driver or SPI hardware has issue.

I guess the bug is in LFSS and it makes RTC failed and SPI speed limited.

Robert.

Hi,

Related to the LFSS? Could you share the schematic related to the MCU especially on the power supply chain VDD, VBAT and VCORE? If it is related to LFSS, it would most likely related to the power supply. 

And one other question, the 1st PCB which has good RTC. Does it also fails on SPI CLK frequency higher than 1MHz? 

Best regards,

Cash Hao

Hi,

Here is the power supply schematic.

VCC = 3.05V. MS621T is 3V Li-battery for RTC. The measured voltage on VBAT > 2.7V.

The 1st PCB also fails with SPI SCLK > 1MHz.

When XMSPM0L2228 was used at the beginning of this project, SPI SCLK can run up to 16MHz. After it was replaced with mass production version MSPM0L2228, it can only run at 1MHz. But at the moment I got MSPM0L2228 samples, I put all XMSPM0L2228 samples into trash can. So, I don't have pre-production chip to test now.

For LFSS, XMSPM0L2228 has critical current leakage issue with VBAT when VDD is turned off. This issue is fixed at MSPM0L2228. I don't know if the RTC also unstable on XMSPM0L2228. At the beginning, I only manually soldered one XMSPM0L2228 for testing and its RTC worked well.

It is my guess. SPI0 pinouts are related to LFSS tamper mode. And the LFSS is revised to fix current leakage issue. Is it possible that the revision has caused potential bugs?

Robert.

Hi,

Why the R2 is used in there? It could lower the voltage on VBAT pin. Could you also try power the VBAT using the same power source as VDD with the R2 removed. Just bypass the battery. I want to check if it is related to the power supply chain issue when the SPI works higher than 1MHz. 

I have not heard any issues related to LFSS on the mass production units. I can check with other team members and check if they have encounter this kind of issue. 

Best regards,

Cash Hao

Hi,

MS621T is rechargeable battery and its capacity is very small (3mAh). When the battery voltage is low, VBAT will charge the battery through R2. R2 is used to limit the charging current, just like using a super cap.

I will test it again with R2 removed and VBAT shorted to VDD. Feedback to you later.

Robert.

Hi,

I have done the test. With R2 removed and VBAT shorted to VDD. The result is the same.

1MHz can work well.

2MHz can work most of the time.

4MHz and above can't work at all.

Robert.

Hi,

Could you take a picture of this MCU's mark and send here? And where do you buy the mass production unit from? Could you also provide your company name? We need these information to check internally on this chip. 

Best regards,

Cash Hao

Hi Robert,

Any updates on this topic? 

Best regards,

Cash Hao

Hi Cash,

I just came back from vacation (Chinese New Year).

Let me reply to you later.

Robert. 

Hi Robert, 

Get it. Happy new year to you too!

Best regards,

Cash Hao

Hi Cash,

Here is the picture:

The MCU was purchased by my customer from TI eStore. I asked my customer to purchase 50pcs for this project from TI eStore when I was notified the production version is ready to purchase.

My company is RCFocus Corp and my customer's company is Stand Tools Enterprise Co., Ltd.

Robert.

Hi Robert,

Get it. And can you give me a email address. I suggest that we can discuss this issue over email. 

Best regards,

Cash Hao

Hi Cash,

My email address: robert@rcfocus.tw

Robert.