Code no longer works while debugging after enabling half-duplex SPI peripheral communication.

CWRB · ‎03-22-2023

Hello everyone,

I am currently working on a project on the i.MXRT1160 and have encountered an issue. Ever since I added an ADC using a half-duplex 4-bit LPSPI connection, the code does not run properly anymore while debugging. The code still works when I flash the device without debugging and the ADC readings seem to be correct. When I start debugging the code breaks and the message in the image below is displayed:

Debugging works again when I disable the half-duplex LPSPI connection, so that seems to be the cause of the problem. Does anyone have an idea what could be going on? The code below shows the configuration of the LPSPI module:

const lpspi_master_config_t LPSPI1_config = {
.baudRate = LPSPI_ADC1_BAUDRATE,
.bitsPerFrame = 56UL,
.cpol = kLPSPI_ClockPolarityActiveLow,
.cpha = kLPSPI_ClockPhaseSecondEdge,
.direction = kLPSPI_MsbFirst,
.pcsToSckDelayInNanoSec = 50UL,
.lastSckToPcsDelayInNanoSec = 0UL,
.betweenTransferDelayInNanoSec = 0UL,
.whichPcs = kLPSPI_Pcs0,
.pcsActiveHighOrLow = kLPSPI_PcsActiveLow,
.pinCfg = kLPSPI_SdiInSdoOut,
.dataOutConfig = kLpspiDataOutTristate,
.width_config = kLPSPI_Width4,
.pcs_config = kLPSPI_PCS_4BitsTransfer
};

static void LPSPI1_init(void)
{
lpspi_which_pcs_t whichPcs;
uint8_t txWatermark;
uint8_t rxWatermark;
uint8_t masterFifoSize;

LPSPI_MasterInit(LPSPI1, &LPSPI1_config, BOARD_BOOTCLOCKRUN_LPSPI1_CLK_ROOT);

whichPcs = LPSPI_MASTER_PCS_FOR_INIT;

/* The TX and RX FIFO sizes are always the same. */
masterFifoSize = LPSPI_GetRxFifoSize(LPSPI1);

if (masterFifoSize > 1)
{
txWatermark = 1;
rxWatermark = 0;
}
else
{
txWatermark = 0;
rxWatermark = 0;
}

LPSPI_SetFifoWatermarks(LPSPI1, txWatermark, rxWatermark);

LPSPI_Enable(LPSPI1, false);
LPSPI1->CFGR1 &= (~LPSPI_CFGR1_NOSTALL_MASK);
/* Flush FIFO , clear status , disable all the inerrupts. */
LPSPI_FlushFifo(LPSPI1, true, true);
LPSPI_ClearStatusFlags(LPSPI1, kLPSPI_AllStatusFlag);
LPSPI_DisableInterrupts(LPSPI1, kLPSPI_AllInterruptEnable);

LPSPI_SelectTransferPCS(LPSPI1, whichPcs);

LPSPI_Enable(LPSPI1, true);
}

I would really like to be able to debug my code with the ADC module activated. Any help is appreciated.

CWRB · ‎03-24-2023

Hello everyone,

I did some further investigation into the issue, and it seems to arise when I set the CFGR1->PCSCFG register of the LPSPI1 module to 0x1, as is required to operate in half-duplex mode. The moment I enable the LPSPI1 module with the CFGR1->PCSCFG register set, the issue arises and the code stops working during debugging. When the CFGR1->PCSCFG register is not set, debugging works as normal, but the ADC readings are incorrect, as the half-duplex communication does not work as it should.

I write to the CFGR1->PCSCFG register while the LPSPI1 module is disabled, as instructed in the reference manual.

I have not yet found a solution to the issue, so any help is welcome.

kerryzhou · ‎03-27-2023

Hi @CWRB ,

Thanks for your interest in the NXP MIMXRT product, I would like to provide service for you.

Please tell me which detail SPI pin you are using now?

What's the RT1160 board you are using? MIMXRT1160-EVK board?

What's the debugger and IDE you are using?

Please tell me more details, then I will help you to check it on my side.

If you are using the MCUXpresso IDE, before you debug the code, please close the register read window in the debug mode, and try it again.

As, if you read the related register, but the LPSPI module still didn't power on clock, it will meet the debug issues, after you run over the LPSPI module clock enable and initialization code, then open the LPSPI register read window again, that should works.

Wish it helps you！

Best Regards,

Kerry

CWRB · ‎03-28-2023

Hi @kerryzhou,

Thank you for your response. I have tried all your suggestions but did not have any luck yet.

I am using the RT1160 on a custom board. On the board, I have got the LPSPI2, LPSPI4, and LPSPI5 modules working without any issues during debugging. All these modules use conventional SPI communication, so not half-duplex.

I am using the MCU-Link debug probe with the MCUXpresso IDE.

The pin configuration of the LPSPI1 module is shown in the image below.

Thanks again for taking a look.

kerryzhou · ‎03-29-2023

Hi @CWRB ,

Do you have the MIMXRT1160-EVK board, whether it also can be reproduced or not?

If yes, you can send me your simplified code which can reproduce the issues on the MIMXRT1160-EVK, then I can help you do the testing in details.

Best Regards,

Kerry

CWRB · ‎03-29-2023

Hi @kerryzhou,

I have tried to run the code on the MIMXRT1160-EVK board and the debugging issue does not occur. I am not able to connect the peripheral that makes use of the half-duplex SPI communication to the EVK board though, so I cannot really confirm if the LPSPI module works as intended.

Below is a simplified version of the code that triggers the issue.

void PWM3_0_IRQHandler(void)
{
uint32_t raw0, raw1;
raw0 = LPSPI_ReadData(LPSPI1);
raw1 = LPSPI_ReadData(LPSPI1);

LPSPI_FlushFifo(LPSPI1, true, true);
LPSPI_ClearStatusFlags(LPSPI1, kLPSPI_AllStatusFlag);

LPSPI1->TCR = (LPSPI1->TCR & ~LPSPI_TCR_RXMSK_MASK) | LPSPI_TCR_TXMSK_MASK;

PWM_ClearStatusFlags(PWM3, kPWM_Module_0, PWM_STS_CMPF_MASK);

SDK_ISR_EXIT_BARRIER;
}

The PWM3_0_IRQHandler is activated at a frequency of 360 kHz in my code. I have tried reducing the frequency to as low as 2 kHz, to see if that would resolve the issue but without success. The issue disappears when I do not set the TCR>TXMSK register, but doing so is required to get the half-duplex communication working.

Is there anything in my code that could trigger the debugging issue?

Thanks again for your time.

kerryzhou · ‎03-29-2023

Hi @CWRB ,

In fact, just the TCR>TXMSK, no directly relationship with the debugger.

Maybe, it is related to your code, meet some issues, and caused the reset or others.

Do you check the debugger log? the code running situation, from where to where?

You also can try disable cache, whether it still meets issues?

Best Regards,

Kerry

CWRB · ‎03-31-2023

Hi @kerryzhou,

Thank you for your response. I have tried disabling the debug memory cache, but the issues remain. Below is the debug log I got. I put a breakpoint in the PWM interrupt handler and continued the code until it crashed.

Program stopped.
PWM3_0_IRQHandler () at ../source/mcmgr_core0.c:485
485 GPIO_PinWrite(GPIO7, 8U, 1);

Temporary breakpoint 2, main () at ../source/mcmgr_core0.c:189
189 {

Breakpoint 1, PWM3_0_IRQHandler () at ../source/mcmgr_core0.c:485
485 GPIO_PinWrite(GPIO7, 8U, 1);

Breakpoint 1, PWM3_0_IRQHandler () at ../source/mcmgr_core0.c:485
485 GPIO_PinWrite(GPIO7, 8U, 1);
/mnt/workspace/workspace/GCC-10-pipeline/jenkins-GCC-10-pipeline-338_20211018_1634516203/src/gdb/gdb/utils.c:671: internal-error: virtual memory exhausted: can't allocate 4064 bytes.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) [answered Y; input not from terminal]

This is a bug, please report it. For instructions, see:
<https://www.gnu.org/software/gdb/bugs/>.

/mnt/workspace/workspace/GCC-10-pipeline/jenkins-GCC-10-pipeline-338_20211018_1634516203/src/gdb/gdb/utils.c:671: internal-error: virtual memory exhausted: can't allocate 4064 bytes.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Create a core file of GDB? (y or n) [answered Y; input not from terminal]

As you can see, the PWM interrupt handler ran a couple of times before it crashed. The number of times the interrupt handler runs before crashing is different each time. I find the "virtual memory exhausted" error interesting. Could that be the cause of the problem?

To further investigate the issue, I created a new multicore project and implemented the half-duplex communication on its own, to see if I would run into the same problem. The same problem indeed occurred. I found that the debugging issue was fixed when I lowered the baud rate of the LPSPI module from 16MHz to 10MHz, but doing the same thing in my original project did not help. Could the issue be caused by too much data being read and the debugger not being able to keep up?

I have attached the test project. Perhaps you see the issue? I have had to make some small modifications to the fsl_lpspi.c file to get the half-duplex communication to work. Perhaps I made a mistake somewhere? The project was too large to send as a single zip file, so I split it up into three.

Thank you for your help,

Kind regards,

@CWRB

kerryzhou · ‎04-02-2023

Hi @CWRB ,

Your test need the SPI slave to do the communication, and reproduce the issues, right?

If just one EVK with your code, still can't reproduce the issues, right?

I have a question, whether it is just related to the debugger, I mean, the debugger lost, if you download the code to the board run without the debugger, whether the code function still works?

From your function, when the PWM interrupt happens, then you read the LPSPI data, right? If the PWM interrupt frequency is not changed, just the PWM frequency changed, then the debugger lost issue happens? If don't connect the ADC module to the LPSPI, just RT1160-EVK running, whether can reproduce the issues or not? If fact, just don't care the adc data.

You also can record one .mp4 to me check the issues.

Best Regards,

Kerry

CWRB · ‎04-05-2023

Hi @kerryzhou ,

You are right, the issue only seems to occur when an SPI slave is connected. I think that is the reason why it works on the EVK without issues.

The code runs when I download the code to the board and run it without the debugger. It only does not work when I try to debug from the MCUXpresso IDE.

I tried changing the PWM frequency, but that did not solve the issue.

I have not been able to recreate the issue on the EVK, as I am not able to connect the ADC to the EVK. Without the ADC connected, the issue does not occur.

I attached two short videos. The orange LEDs on the PCB indicate that the PWM interrupt is active and the ADC is being read out. When debugging the LEDs light up briefly, but turn off shortly after and the code stops running. When running the code without the debugger, they light up and remain lit, meaning the code is running.

Note: The error windows in the video with the debugger connected popped up after I tried pausing the debug session.

I hope the videos make the issue more clear.

Thank you for your help,

Kind regards,

@CWRB

kerryzhou · ‎04-07-2023

Hi @CWRB ,

Thanks for your updated information.

I think this is good: The code runs when I download the code to the board and run it without the debugger.

At least, your project can move forward.

Could you help to test this situation: don't use the PWM interrupt, just write a simple code add the LPSPI, then whether it reproduce the issues or not?

I mean, this code:

uint32_t raw0, raw1;
raw0 = LPSPI_ReadData(LPSPI1);
raw1 = LPSPI_ReadData(LPSPI1);

LPSPI_FlushFifo(LPSPI1, true, true);
LPSPI_ClearStatusFlags(LPSPI1, kLPSPI_AllStatusFlag);

LPSPI1->TCR = (LPSPI1->TCR & ~LPSPI_TCR_RXMSK_MASK) | LPSPI_TCR_TXMSK_MASK;

PWM_ClearStatusFlags(PWM3, kPWM_Module_0, PWM_STS_CMPF_MASK);

Just write a API to call it, and in the main while, don't use PWM, whether debug works when you call TCR>TXMSK?

Best Regards,

Kerry

CWRB · ‎04-13-2023

Hi Kerry,

I have tried to run the code outside of the PWM interrupt in a new project and the problem indeed does not occur. When I put the code back into the PWM interrupt, the issue recurs.

Weirdly, in my actual project, moving the code outside the PWM interrupt does not solve the issue. I tried disabling all other interrupts as well, but without any success.

When trying some stuff in my test project, I found that the connection between the SPI module and MCU influences the issue. When I connect the module directly to the MCU by connecting their respective PCBs, the SPI communication works for high baud rates (16MHz) during debugging. When I use an adapter board (to more easily measure the signals with an oscilloscope) the SPI communication only works for lower baud rates (<10MHz). For higher baud rates the debugging issue returns. High baud rates can be used while using the adapter board when running the code without debugging.

Perhaps some timing issues occur when debugging while using the SPI communication? Or perhaps there is some interference between the debug signals and the SPI signals? Do you have any Idea?

Kind regards,

@CWRB

kerryzhou · ‎04-14-2023

Hi @CWRB ,

So, seems still related to your project, not just the SPI.

Do you also try to comment the PWM interrupt in your project, whether that works or not?

Best Regards,

kerry

CWRB · ‎04-24-2023

Hi @kerryzhou,

Yes, I have also tried disabling the PWM interrupt by commenting it out. It sadly did not solve the issue.

Kind regards,

@CWRB

kerryzhou · ‎04-25-2023

Hi @CWRB ,

You mentioned:

I have tried to run the code outside of the PWM interrupt in a new project and the problem indeed does not occur. When I put the code back into the PWM interrupt, the issue recurs.

Weirdly, in my actual project, moving the code outside the PWM interrupt does not solve the issue.

So, seems related to your project, can you try to test it on the NXP EVK, whether it can be reproduced or not? I mean, you can simplify it, or test your project directly, whether that can reproduce or not?

Another method, your own project, copy it, then comment API in the main one by one, just to check, which detail code may influence it.

Best Regards,

Kerry