This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

LAUNCHXL-CC3235SF: Hardware exception reading data from ADS and sending UDP datagrams

Part Number: LAUNCHXL-CC3235SF
Other Parts Discussed in Thread: CC3235SF, ADS1298

Dear simplelink team,


We are having hardware exception problems implementing the following program in the CC3235SF:
The functionality is quite simple: the MCU reads SPI data from the 8 channels of an ADS1298 with a sampling rate of 2000 samples/s and sends these data through UDP packets over the WiFi connection. The program is based on the example code "udpecho" included in the Simplelink SDK 6.10 demos.


We have changed the code to send UDP datagrams as soon as the data buffer is full.We have used buffer sizes from 300 to 1400 bytes.
As soon as the program starts and the device connects to the WiFi network, the udp thread waits in a semaphore:

...
ads_start();
while(1)
{
   Semaphore_pend(semAPP, BIOS_WAIT_FOREVER);
   sendBuffer();
}

The sendBuffer routines is coded as follows:
void sendBuffer()
{

     bytesSent=sendto(server, buffer_ads,UDP_PACKET_SIZE, 0,(struct sockaddr *)&clientAddr, addrlen);
    ads_enableInt();
}

The ADS is configured to trigger the DRDY line and a Gpio interrupt reads the data through SPI into the buffer.As soon as the buffer reaches the size of the UDP payload packet, the hardware interrupt routine posts the semaphore to allow the task to send the data. While the task is sending the data the GPIO interrupt is disabled. The function is coded as follows:

void ADS1x9x_ReadData()
{
   GPIO_write(ADS_CS,ADS_CS_ON);

   ads_spiTransaction.count = 3+24;
   ads_transmitBuffer[0]=0;

   ads_spiTransaction.txBuf = NULL;
   ads_spiTransaction.rxBuf = (void *)ads_receiveBuffer;

   ads_transferOK = SPI_transfer(ads_spi, &ads_spiTransaction);

   GPIO_write(ADS_CS,ADS_CS_OFF);

   if(ads_transferOK)
   {
        uint8 idx=0;

       if(cnt_bytes+BYTESxSAMPLES>UDP_PACKET_SIZE)
      {
             cnt_bytes=0;
             Semaphore_post(semAPP);

     }else
     {
                   for(idx=0;idx<BYTESxSAMPLE;idx++) buffer_ads[cnt_bytes++]=ads_receiveBuffer[idx];

     }
  }
}


However, the program after a few seconds hangs in a loop within the Hwi exception handler routine: rm_m3_Hwi_excHandlerAsm__I.

If the function sendTo is not called (sendBuffer commented out) the program works always ok reading the ADS data without stop.
If we reduce the sampling rate to 1000 samples/s it also works fine all the time.The SPI is working at 18Mbps.

My questions are:
Any suggestions regarding this problem and how to solve it ?
How can we debug the reason for this exception?. Can the sendTo function generate a hardware exception?. Is the MCU not able to carry out this demanding task?.

Thanks

  • It looks like a memory corruption (e.g. stack overflow) that causes the exception (e.g. jumping to an out-of-range address).

    There is no easy way to debug such issues.

    You can try to check the stack size (or just increase them for debugging), increase the heap size in case you are allocating data without checking the return value.

    Make sure you are checking return codes for the functions.

    There is no known issues with "sendto". You are calling it from an application task (thread) context, right?

       

  • Thanks Kobi for your answer.

    We eventually solved the problem. We were reading some ADS registers through SPI inside the Hwi and as soon as we increased the sample rate to 2ksamples/s, the exception used to jump. We have moved any access to the SPI bus outside the Hwi. The hwi routine only post a semaphore.

    Could you please give us any link to documentation with recommendations regarding hwi routines best practices?. Thanks

    Regards 

  • You can check in the Technical Reference Manual (https://www.ti.com/lit/pdf/swru543) or in the drivers (/docs/drivers/doxygen) documentation in the SDK.

    But I'm not sure these have "best practices" section. The rule about the hwi use is general. You should always try to avoid this if possible.