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.

After update MAP_SPI_getInterruptStatus doesn't work, but SPI_getInterruptStatus works

Other Parts Discussed in Thread: MSPWARE, CC1200, MSPDRIVERLIB, MSP432WARE

Yesterday I updated MSPWare432 to the newest verstion. After the update I found an function that didn't work, to work, and I found a function that did work, but now doesn't any more. I am very concerned about this because I am we are making a new product with MSP432 and using MSPWare and I am afraid to write big chunks of code for it and when an update comes, some things don't work any more.

I'll give a part of the code I used but that should be enough. I am communicating with the CC1200. Before update everything worked with the MAP_SPI_getInterruptStatus(RF_SPI, RF_SPI_TRANSMIT_INTERRUPT); but now it doesn't wait for the transmit interrupt to be ready and overwrites. I was looking on the SPI lines on my oscilloscope and when i remove MAP_ prefix it works. I also saw that now in the examples you don't use MAP functions any more.

One last thing. Where can I find the update notes for the MSPWare432?

// Defines
#define RF_SPI EUSCI_B0_BASE
#define RF_SPI_TRANSMIT_INTERRUPT EUSCI_B_SPI_TRANSMIT_INTERRUPT
#define RF_SPI_RECEIVE_INTERRUPT EUSCI_B_SPI_RECEIVE_INTERRUPT


void ConfigureRFBurstAccess(const registerSetting_s* config) { uint32_t i; SelectRFModule(); // Command byte that says burst write from address 0x00 TransmitByteToRF(0x40); for(i = 0; i<0x2F; i++) { TransmitByteToRF(config[i].value); } // The CSn for RF needs to be pulled up to cancel the // burst into the register space and then it needs to // be pulled down again to start burst into extended // register space DeselectRFModule(); SelectRFModule(); // Command byte that says burst write in extended register space TransmitByteToRF(0x6F); // Command byte that says from which address to burst write TransmitByteToRF(0x00); for(i = 0; i<0x3A; i++) { TransmitByteToRF(config[i+0x2F].value); } DeselectRFModule(); } void TransmitByteToRF(uint8_t byte) { // Wait for transmit buffer to be empty and transmit byte while (!(SPI_getInterruptStatus(RF_SPI, RF_SPI_TRANSMIT_INTERRUPT))); MAP_SPI_transmitData(RF_SPI, byte); } uint8_t ReceiveByteFromRF() { while (!(SPI_getInterruptStatus(RF_SPI, RF_SPI_RECEIVE_INTERRUPT))); return MAP_SPI_receiveData(RF_SPI); }

  • I apologize for the confusion that you are experiencing with the MSPDRIVERLIB which is caused by the recent split into 430 and 432 libraries. In older versions the MAP_ prefix would distinguish between the different libraries but now that they are separated this prefix is no longer necessary and can actually hinder functionality since it still refers to old functions which are no longer used. They should as such be removed from your firmware. The benefit to all of this is now that the libraries have been divided, future MSP432WARE updates should not cause pieces of your application code to crash. Release notes can be found on the MSP432WARE and MSP432_Driver_Library software download pages:

    software-dl.ti.com/.../release_notes.html
    software-dl.ti.com/.../release_notes.html

    Regards,
    Ryan
  • Thank you very much for your answer. It really cleared most things up.
    The MAP_ prefix that was used was making us use functions that are in the ROM of our CPU-s if I remember correctly. This would save us a lot of space if we would use all MAP_ functions. Is there some alternative to that now or is there a chance we will be using the MAP_prefix in the future?
  • I don't believe for SPI functionality the MAP_ prefix will return, but keep in mind that this change does not apply to most peripherals. For example: I2C, DMA, and TIMER_A examples still use the MAP_ prefix, the SPI peripheral is one of the few that was affected by the recent changes.

    Regards,
    Ryan
  • I went through the whole documentation and the links you gave to me. I am grateful for that as I understand some things better then before. But don't you think there are a few confusions in your examples? I find it very confusing that in some GPIO example you use MAP_ prefix and in some SPI examle, for the same functions, you don't use MAP_. Also I could not find anywhere which functions I can use with MAP_ and which I can't.
  • I will confer with the MSP432 DriverLib authors to provide more insight on this matter. This is valuable feedback that will be taken into consideration for future updates.

    Regards,
    Ryan
  • Hi jasaleja,

    Is your MSP-EXP432P401R red or black? Pre-release silicon (black LaunchPads) are not supported with new versions of DriverLib (3_21_xx later) and should be downgraded accordingly.  You should consider ordering a new LaunchPad as the old ones will no longer be supported moving forward.

    Regards,
    Ryan

  • Hi Ryan,

    It is black and that is bad news for me. We will soon be ordering MSP432P401R for our products and i supose we can use the new driverlib with the new ordered mcu. Can I know what is the reason for not supporting the black ones? It would be easier for us to avoid the problem with the new driverlib then downgrade. But if we must, we will.

    jasaleja
  • Hello jasaleja,

    As stated before, the black LaunchPads include pre-release silicon and now that TI has fully released the MSP432P401R only these versions will be supported. Since the parts you are ordering will all be post-release this makes it all the more important to be testing on a red LaunchPad.

    Regards,
    Ryan

**Attention** This is a public forum