• State Resolved
  • Locked Locked
  • Replies 14 replies
  • Subscribers 78 subscribers
  • Views 6603 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Compiler/MSP430FR5994: MSP430 intrinsics with BOOSTXL-AUDIO questions

Benjamin Paik
Intellectual 600 points
Part Number: MSP430FR5994
Other Parts Discussed in Thread: BOOSTXL-AUDIO, , MSP-EXP430FR5994, MSP430WARE

Tool/software: TI C/C++ Compiler

I am currently using the MSP430FR5994 launchpad with the BOOSTXL-AUDIO boosterpack to evaluate the BOOSTXL-AUDIO Record Playback example project, and have a few questions regarding the  "__data20_read_short" intrinsic function. When reading the MSP430 Optimizing C/C++ Compiler Guide, there are a number of similar intrinsics listed (such as  __data16_read_addr, __data20_write_char, etc.). I assume the purpose of these is to transfer data into and out of FRAM, is that correct? Are they necessary to access FRAM or do they simply use fewer clock cycles? What is the meant by the __data16 and __data20 prefixes? Thanks.

I also wanted to note that the project does not import to CCS through Resource Explorer. After downloading MPS430Ware -v:3.80.01.01 and navigating to the BOOSTXL-AUDIO Record Playback project for the launchpad, CCS shows the following message:

Cannot GET /examples/boards/MSP-EXP430FR5994/MSP-EXP430FR5994_Software_Examples/Firmware/Source/BOOSTXL-AUDIO_RecordPlayback_MSP430FR5994/CCS/BOOSTXL-AUDIO_RecordPlayback_MSP430FR5994.projectspec

This seems to be the case for the other demos in Development Tools/MSP-EXP430FR5994 as well, even though the actual file path seems to line up (C:\ti\msp430ware_3_80_01_01\examples\boards\MSP-EXP430FR5994\MSP-EXP430FR5994_Software_Examples\Firmware\Source\BOOSTXL-AUDIO_RecordPlayback_MSP430FR5994). I was able to get around this by using Project -> Import CCS Projects and navigating to the directory, but it might be worth investigating for other users.

  • 0
    TI__Genius 15370 points
    Hi Benjamin,

    Let me first address the easy one. The error you're receiving when trying to import the examples is a known issue that is currently being addressed. Also, the issue appears to only be present for MSP430Ware v3.8. So if you use v3.6 you shouldn't experience this error.

    Now onto the intrinsic functions. The __data20_read/write and __data16_read/write functions are used to access the 20 and 16 bit memory spaces respectively. The MSP430FR5994 is a 16 bit device but has 256KB of FRAM. To be able to use this large of a memory space, some of the addresses must be 20 bit numbers (0x10000 - 0x43FFF). These addresses can't be accessed using the normal 16 bit instructions so the intrinsic __data20_read/write instructions are provided. It should also be noted that it is not necessary to use the __data16_read/write functions to access the lower 16 bit memory space but it is required to use the __data20_read/write functions to access the upper 20 bit memory space. I hope this clears things up a bit and let me know if you have any further questions.

    Best regards,
    Caleb Overbay
  • 0 in reply to Caleb Overbay
    Intellectual 600 points
    Thanks for getting back to me; I do have a follow up question for you. The original post here was made while I had the launchpad, but was still waiting to receive the BOOSTXL-AUDIO boosterpack. I have since received it and tried running the record playback demo, but it doesn't seem to be working. I can program the launchpad, and the buttons and LEDs behave as described in the documentation. However, when trying to play recorded audio, the speaker just produces a periodic clicking noise, regardless of what was recorded. I thought the speaker might have been damaged, so I tried playing through headphones and I heard the same clicking sound through the headphones (the volume dial does control the volume of the clicking sound). I verified that the jumper was placed on the SPI_DAC header, and that the 0 Ohm resistors were placed in the default configuration. Is this a known issue that can be easily resolved? Or does it seem like the hardware is damaged in some way? If so, is there contact information for returns (I wasn't able to find any)?

    I will go through some basic hardware debugging soon (checking SPI signals, DAC waveforms, etc.) and provide additional information if the issue isn't apparent.
  • 0 in reply to Benjamin Paik
    TI__Genius 15370 points

    Hi Ben, 

    I'm not aware of any known issues with the BOOSTXL-AUDIO boosterpack. Have you made any changes to the default code or have you made any deviations to the instructions in BOOSTXL-AUDIO Audio BoosterPack Plug-in Module User's Guide? Have you made any progress debugging the issue?

    Best regards, 
    Caleb Overbay

  • 0 in reply to Caleb Overbay
    Intellectual 600 points
    I haven't made any code changes or deviations from the instructions. While checking out the board I verified that SPI CLK, CS , and MISO were all being generated correctly during playback. However, MISO only outputs 0x3FFF or 0x0000 regardless of what was recorded (basically rail to rail for 14-bits). I thought this might indicate issues with the microphone amplifier circuit, but MIC PWR and MIC OUT were both present and valid when recording (MIC OUT looked like a typical audio waveform and scaled properly). I tried to look at the data in the dataRecorded buffers in CCS, but they simply read all zeros after recording audio. I suspected this had to do with the fact that the previously mentioned intrinsic functions are required to access these memory locations, and thus are not accessible as Expressions in Debug.
  • 0 in reply to Benjamin Paik
    TI__Genius 15370 points

    Hi Ben, 

    You should be able to properly view the content of the dataRecorded buffer via the Expressions window regardless of where it's located in FRAM. As a double check you can view the dataRecorded buffer via the Memory Browser and see if it matches what you see in the expressions window. If the buffer is still zero, it appears that the mic may not be recording audio correctly. In this case, can you try recording the audio through a mic attached to the headphone jack instead of the on-board mic? This will let us know if the mic is failing. Let me know the results and we'll work from there.  

    Best regards, 
    Caleb Overbay

  • 0 in reply to Caleb Overbay
    Intellectual 600 points
    I checked both Expressions watch and Memory Browser and both report all zeros. I don't have a headset to test with at the moment, but looking at the schematic for the BOOSTXL-AUDIO shows that both the headset mic and on-board mic go through the same mic amplifier circuit. I checked MIC OUT (which is the ADC input on the launchpad) with my scope and verified that the audio signal was present while recording. It seems then that the on board mic is working properly, so if there is damage, I would think it would be at the ADC input.
  • 0 in reply to Benjamin Paik
    TI__Genius 15370 points
    Hi Ben,

    From what you've described above, it's looking like this could be an issue with the ADC. Typically when an ADC is only returning either 0 or full readings I become suspicious of the reference voltage. In this case the ADC should be setup with AVcc and AVss as Vr+ and Vr- respectively. If the board is powered correctly then your ADC ref should be correct as well but it's worth checking Avcc to ensure it is at the correct level.

    Have you made any further progress debugging this issue?

    Best regards,
    Caleb Overbay
  • 0 in reply to Caleb Overbay
    Intellectual 600 points
    I've since tested the board with an external mic/headset and it still produces the same result. I've verified that AVcc and AVss are correct, but it seems you mean to route these to Vref+ and Vref-. For this board, the pins are currently being used for LED 1 and LED 2. Does setting REFOUT automatically override the GPIO output settings?
  • 0 in reply to Benjamin Paik
    TI__Genius 15370 points

    Hi Ben,

    When selecting the Avcc and Avss as the ADC reference voltages there is no need to route then to the Vref+ and Vref- pins. The connections are made internally to the device. Do you have a second MSP-EXP430FR5994 launchpad that you can test the BOOSTXL-AUDIO on?

    If not, can you test the ADC without the BOOSTXL-AUDIO board disconnected using the msp430fr599x_adc12_11.c example found in TI Resource Explorer? This example is similar to how the demo code for the BOOSTXL-AUDIO booster pack works. I would suggest changing the ADC setup in this example code to the same setup being used in the BOOSTXL-AUDIO code so that the same channel and settings are being used. Then supply different voltages to the ADC input and check to see if the converted values are what you expect. This will let us know if the ADC is operating incorrectly and if there is a possibility of damage. Let me know if you have any questions. 

    Best regards, 

    Caleb Overbay

  • 0 in reply to Caleb Overbay
    Intellectual 600 points

    I don't have a second launchpad to test with. Interestingly enough, the example project you suggested worked as advertised on the same ADC channel being used for the mic input. Given that the ADC input appears to be functional and the audio signal is present on the scope when recording audio, I'm not sure what the problem could be. I tried loading the BOOSTXL-AUDIO example project again from a different PC with a fresh installation of CCS7 and reimported the project, but the problem persists.

  • 0 in reply to Benjamin Paik
    TI__Genius 15370 points
    Hi Ben,

    I want to give you a quick update on this. I've identified a bug that is causing this issue and I'm working on a solution. It's a little bit involved so it's taking some time. I'll get you an update tomorrow along with the fix and an explanation of the issue. Thanks for your patience!

    Best regards,
    Caleb Overbay
  • 0
    TI__Genius 15370 points

    Hi Ben, 

    I've attached a new custom linker file for this project. The root cause of the issue is the dataRecorded buffers were being placed in a section of memory that was write protected by the MPU. To solve this, I defined a new memory section in the linker file called "audio" that starts at the beginning of FRAM2 (0x10000). I then used the MPU to segment the devices memory into 3 segments.

    Segment 1 is contains persistent variables and can vary in length depending on the size of the variables in persistent memory. Segment 1 also has read and write permissions. Segment 2 contains the code and starts at then end of segment 1 and ends at the beginning of FRAM2 (0x10000). Segment 2 has read and execute permissions but cannot be written to. Finally, Segment 3 contains the recorded audio data and starts at the beginning of FRAM2(0x10000). Segment 3 has read and write permissions. 

    All this segmentation was done in the linker file. In addition to replacing the default linker file in your project, you'll need to change the definition of the dataRecorded buffers in audio_collect.c file to:

    #pragma DATA_SECTION(dataRecorded1, ".audio")
uint16_t dataRecorded1[SAMPLES_LENGTH] = {0};

#pragma DATA_SECTION(dataRecorded2, ".audio")
uint16_t dataRecorded2[SAMPLES_LENGTH] = {0};

    This will cause these buffers to be placed in the newly defined ".audio" section which is contained the the MPU Segment 3. After making these changes everything should work appropriately. This bug was caused because of an older bug that in now fixed that was causing the MPU to be disabled. I'm taking action on my end to permanently fix this in future updates. If you have any questions feel free to ask. 

    lnk_msp430fr5994.cmd

    Best regards, 

    Caleb Overbay

  • 0 in reply to Caleb Overbay
    Intellectual 600 points
    Using your latest suggestion, I was able to get the launchpad to function with the boosterpack. There still seems to be a bug in the playback feature that causes the recording to play non-sequentially. For example, if I record myself saying "1,2,3,4,5,6,7,8", the audio that gets played back is "1, pause, 5,6,2,3,4". However, at this point I am confident enough with the hardware to proceed with my project. Please let me know if you have any further insight regarding this issue. Thanks.
  • 0 in reply to Benjamin Paik
    TI__Genius 15370 points
    Hi Ben,

    Glad to hear things are at least partially working. I was experiencing this playback issue but adding the custom linker file seemed to alleviate it upon initial testing. I'll take a closer look and let you know what I find. Is there anything else I can help you out with for your project?

    Best regards,
    Caleb Overbay

**Attention** This is a public forum