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.

TMS570LC4357: TMS570LC4357: Hercules™︎ safety microcontrollers forum - ENABLING 256 BUFFERS OF MIBSPI1

Part Number: TMS570LC4357
Other Parts Discussed in Thread: HALCOGEN


I have checked the mibspiREG1->LTGPEND register and it is 4+222+30-1 . I did not make any change because Halcogen automatically changes this register from "4+94+30-1" to "4+222+30-1" when I change MIBSPI TG1 from 94 to 222. Halcogen automatically updated the "HL_mibspi.c" file. To be short, yes mibspiREG1->LTGPEND register is like below:

The problem still persists, is there any other adjustment that I need to make ?

  • When you modify the code generated by HALCoGen, please insert the new code into the  USER CODE sections (between 'USER CODE BEGIN" and "USER CODE END"). Otherwise, the inserted code will be deleted when HALCOGen generates new code for you.

    By default, the MibSPI supports up to 128 buffers for both TX and RX. To enables the support for 256 buffers, please write 0xA to EXTENDED_BUF_ENA field of MIBSPIE register in main() or in the USER CODE section 3 in mibspiInit().

  • Dear Wang,

    Thank you very much for your quick response. I get excited every time I try, but I still couldn't reach a result. The last situation is this:

    I have set the TG0 Length->4, TG1 Length->220, TG2 Length->15 in the MibSPI1 section in Halcogen. Then I have generated the code and turn back to CCS window. In the "HL_mibspi.c" file I have made change like below:

    To write 0xA to EXTENDED_BUF_ENA  register, I wrote:

    To check "mibspiREG1->LTGPEND = 4 + 222 + 30 - 1" is right? 


    Yes this is right too.

    When I compile and load the program to MCU, I get stuck at  "while(mibspiIsTransferComplete(mibspiREG1,1)==0);"  again.

    Do I need to make any other configuration? 

  • NOTE: I accidentally pressed the "this resolved my issue", sorry. Could not take it back.

  • "mibspiREG1->LTGPEND = 4 + 222 + 30 - 1 is not correct. The correct value for LTGPEND is:

    mibspiREG1->LTGPEND = (mibspiREG1->LTGPEND & 0xFFFF00FFU) | (uint32)((uint32)((4U+222U+15U+0U+0U+0U+0U+0U)-1U) << 8U);

  • I will do a test of using 256 buffers tomorrow.

  • I'm so sorry, I sent the wrong image. LGTPEND image would look like this:

  • Thank you, I would be grateful

  • I did a test this morning. The extended buffer mode should be enabled before the buffers are initialized. If it is enabled at the end of mibspiInit() function, the control field of buffers[255:128] are cleared, and data in those buffers won't be transferred.

    The workaround for the HAL generated mibspiInit() is:

    If you use all 8 transfer groups, the LPEND is 255. You need to modify the code of mibspiSetData() and mibspiGetData() to set data for extended buffers and get data from the extended buffers. Please change 7F to FF in the following two functions:

    void mibspiSetData(mibspiBASE_t *mibspi, uint32 group, uint16 * data)



         uint32 end = (group == 7U) ? (((mibspi->LTGPEND & 0x00007F00U) >> 8U) + 1U) : ((mibspi->TGCTRL[group+1U] >> 8U) & 0xFFU);


    uint32 mibspiGetData(mibspiBASE_t *mibspi, uint32 group, uint16 * data)

        uint32 end = (group == 7U) ? (((mibspi->LTGPEND & 0x00007F00U) >> 8U) + 1U) : ((mibspi->TGCTRL[group+1U] >> 8U) & 0xFFU);


    This changes are only applied to MibSPI1. MibSPI1 supports 256 buffers (values from 0-FFh), bit 15 is used of LTGPEND. For MibSPI2-5 that support 128 buffers (values from 0-7Fh), bit 15 is reserved.

  • Dear Wang,

    Thank you very much for your support. Now, when I sent 220 byte over mibSPI1 my code does not stuck at "while(mibspiIsTransferComplete(mibspiREG1,1)==0);" . But I am facing with the new problem, I could not receive data over SPI.

    I have wrote 0xA00 to MIBSPIE register as you describe and I have changed 7F to FF.  The code is built and loaded into the MCU and I realized that I could not get any data from my "read_register" function, over MıbSPI1. I was able to get 0xAA55 (return var2) data before enabling MıbSPI1 256 byte buffer. But after the change we made, var2 returns as 0. I have changed nothing in the TG0 and "read_register" function. The TransferGroup's configuration and "read_register" function is as below:

    TG0 Length --> 4 ; TG0 Length --> 220 ; TG0 Length --> 15 ; .... The others are 0.

    Note: "send" and "receive" array index' are declared as uint16 because "mibspiSetData" function takes their pointer as uint16. 

    I have no idea why I was able to get var2 as 0xAA55 before activating 256 Byte buffer but not after activating it.

    When I undo the change I made to create a 256 Byte buffer, the var2 variable could return as 0xAA55.

    I'm late in replying because I was looking for a solution to the problem, but I couldn't find it, I want your support again, thank you very much in advance for your support.

  • From the code snapshot, the data in array send[] is copied to MibSPI RAM and transmitted. Where is 0xAA55 or 0xDA00 is transmitted? Do you use loopback mode?

  • I am using "PLC Stamp Mini 2" module ( )that communicates with TMS570LS43XX over SPI. I am not using loopback mode. At the first stage of the host controller code, TMS570LS43x sends signature query in this format;

    The Module returns as : 

    I am using internal registers of the Module to read signature(0xAA55). Before writing 0xAh to MIBSPIE EXTENDED_BUF_ENA register, I was able to return this 0xAA55 value in the "read_register" function. I have no idea how the change we made could affect that.

    As a further information, when I want the module to send data out, which is an ethernet frame, the amount of bytes I need to send is around 150 at least.

    This is the screenshot from the Module's datasheet about the external writing (sending data to out) : 

    The chip select pin is pulled to low and the long data to be sent out by the module is started to be sent from the TMS570 to the Module from the MOSI pin. With this technique, the data length I need to send is around 150 bytes. That's why I was trying to activate the 256 Byte buffer.

    It's a bit difficult to explain the subject here, I hope I was able to answer your question. If there is any additional information I need to convey, I will write immediately.

    Best regards.

  • Hello,

    Have you resolved the extended buffer issue?