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.

RTOS/J6EVM5777: Flashing SYSBIOS to J6EVM Board to boot up the code from flash

Part Number: J6EVM5777
Other Parts Discussed in Thread: SYSBIOS

Tool/software: TI-RTOS

Hi,

i am trying to run my DSP sysBios source code on the J6EVM Eval Board without the JTAG and CCS7.

In the last days, i did some research on the ti web site and the wiki about my project. I found only this site with some informations about the linux boot from my Jacinto 6 Evaluation Board. But this is not what i want to do.

My application is a SysBios implementation that runs very well on the DSP, but it runs only together with the JTAG and CCS7.

How can i flash the .out file to the DSP and how can i start/boot my programm with the ARM A15 from flash memory?

From my understanding, the ARM A15 is the master and all other controllers are slaves. That means the ARM A15 must enable the DSP and load my compiled application from flash into the DSP. Is this correct?

It's would be nice to have an example code with an documentation or start up guide.

best regards

Paul

  • Hi Paul,

    I have forwarded your question to TI-RTOS expert.

    Regards,
    Yordan
  • Hi Paul,

    You are correct in your understanding that A15 is the boot master of the system and is responsible for loading the other cores.

    Could you give more information about the application you are running? Specifically, are the A15s active while the DSP application is running? If so, is it running on a high-level OS like Linux or Android, or is also going to be running SYS/BIOS? Or, maybe A15s are idle in your scenario? There are various SDKs available which can help you achieve what you are asking, so I just want to make sure I point you in the right direction.

    Thanks,
    Stephen
  • Hi Stephen,

    thanks for your fast reply.

    My project is a DSP only project. That means the A15 core is in idle state. On the DSP, i am using the sysBios only without linux or android system.

    For now i can run my code on the DSP with the CCS debug functionality in standalone mode. Here are my procedure in detail:

    -> Power up the eval board
    -> connecting to A15 via CCS and run the GEL script DSP1SCLKEnable_API
    -> Now i can connect and run my code on the DSP without A15 project

    Where i can find a sysBios example code for the A15 for activating the DSP and how can i flash the J6EVM to run my application without CCS?

    best regards

    Paul
  • Hi Paul,

    Thanks for the additional info.  Based on what you mention, I would suggest the Processor SDK RTOS Automotive which is the DRA7xx SDK for RTOS applications.  You can download this from the DRA7xx SW landing page: 

    http://www.ti.com/tool/PROCESSOR-SDK-DRA7X

     

    From here, I would point you to the Secondary Boot Loader component under <SDK_INSTALL_PATH>/pdk_dra7xx_1_0_8/packages/ti/boot/sbl_auto.  This is the A15 boot strap application that can handle loading up all or some of the cores on the J6 device with an application.  For your purpose, you can create a DSP1-only application image.  The supported boot modes are SD, QSPI flash, and NOR flash.  You can review the documentation on specific instructions for how to create the image.

    Let me know if you have any questions.

    Thanks,
    Stephen

  • Paul,

    Not sure what happened with the formatting in my last post, but below the download page, I also tried to point you to the release notes for supported features and devices:
    processors.wiki.ti.com/.../Processor_SDK_RTOS_Automotive_Release_Notes

    For this SDK, we use DRA75x naming convention for J6/J6EP/J6EX devices. DRA72x is for J6Eco.

    Thanks,
    Stephen
  • Hi Stephen,

    Thanks for your great help and i am on a good way. I flashed now the SBL on the QSPI memory and got the following message from the board:

    TDA2Ex SBL BootDPLL Configuration Completed
    Clock Domain Configuration Completed
    Module Enable Configuration Completed
    TI EVM PAD Config Completed
    DDR Config Completed
    App Image Download Begins

    Manufacturer ID - 0x1
    Device ID - 0x18

    Invalid Magic String in MultiCore Image
    Valid App Image is not Available
     
    *****************************************************************
    PMCCNTR counts once every 64 clock cycles, multiple by 64 to get actual CPU cycles

    SBL Initial Config Cycles - 65115  (5.20 ms) <\r><\n> SOC Init Cycles - 174118  (13.92 ms)
    DDR Config Clock Cycles - 45747  (3.65 ms) <\r><\n> App Image Load Cycles - 266357  (21.30 ms)
    Slave Core Bootup Cycles - 14248  (1.13 ms) <\r><\n> SBL Boot-up Cycles - 566667  (45.33 ms)
    Time at which SBL started IPU1_0 - 40354834  (3228.38 ms)
    *****************************************************************
    Putting MPU in Retention...

    The issue is now, the SBL can't find the App Image. Maybe i do some mistakes at the flash procedure. What i try to do is the following:

    I flashed the SBL at 0x0 and the App Image at offset 0x80000. The App Image needs also special data, can i flash this data after the App Image? The memory should look like this at the end:

    0x0          SBL

    0x8000   APP IMAGE

    0xXXXX DATA for App Image

     

    0xXXXX ... Depends on the App Image size.

     

    Thanks

    Paul

  • Hi Paul,

    Is the AppImage in BE format? Also you need to flash it 0x80000 (0x8000 is mentioned at one place and 0x80000 at other).

    Regards,
    Rishabh
  • Hi Rishabh,

    i tested both LE and BE at the offset 0x80000. The offset in my last reply was a mistake in writing. Both created AppImages are not working and i get evreytime the same message "Invalid Magic String".

    Here are the header of my AppImage:

    bc e7 01 00 00 00 30 40 4d 53 54 52 01 00 00 00 18 00 00 00 00 00 00 00 00 00 00 00 b4 e7 01 00 00 00 00 00 01 00 00 00

    Should i compile the ELF file in big endian, too? Because this is still in little endian.

    regards

    Paul
  • ok, i think the endianness of my application out file is wrong. I build my application in little endian and i can't compile it in big endian. Because the sysBios isn't supporting big endian for c66. The compiler is returning the following error inside CCS:

    "ti.sysbios.family.shared.vayu.IntXbar : Target C66_big_endian is not supported. .xdchelp"

    Can i boot my AppImage vom SD card in little endian? I can't find some information about this point. Only this line:

    "ENDIAN (BE/LE): specifies whether the out file is in Big Endian/Little Endian format. For QSPI/SPI boot mode application image should be in BE, for other boot modes application image should be in LE."

    regards

    Paul

  • Hi Paul,

    From SYSBIOS you will get LE format only. Then you have to add GP header to it using tiimage tool.

    This tool takes LE or BE as one of the arguments. For SD boot you should use LE as argument and for QSPI you should use BE as argument.

    Please look at SBL user guide document. It explains this in detail.

    Regards,

    Rishabh

  • Hi,

    i found my mistake. I don't need a conversion of the bin file into a tiimage. The bin file after the MulticoreImageGen.exe is the final AppImage.

    Now the code is successful loaded with a seperate entry point adressing inside the cfg file:

    Program.sectMap[".init  { boot*(.text) }"] = new Program.SectionSpec();
    Program.sectMap[".init  { boot*(.text) }"].loadAddress = 0x80031EC0;

    This line of code gives me the ENTRY POINT SYMBOL: "_c_int00"  address: 80032000.

    For now my app image is loaded, but not running on the DSP1. I only gets the following returning  "Putting MPU in Retention...". My App image includes the my app binary for DSP1, only. Is this correct? Or do i need a start up code for the CPU0? Or is it nessesary to change the sbl_tda2ex_main.c file in line 457?

        /* Jump to MPU CPU0's entry point */
        if (0U != sblEntryPoints.entryPoint[SBLLIB_CORE_ID_MPU_CPU0])
        {
            SBLLibPrintf(SBLLIB_TRACE_LEVEL_IMP_INFO,
                         "\n Jumping to MPU CPU0 App \n");
            UARTWaitUntilTransmitComplete();
            mpuCore0EntryFuncPtr =
                (EntryFuncPtr_t) (sblEntryPoints.entryPoint[
                                      SBLLIB_CORE_ID_MPU_CPU0]);
            mpuCore0EntryFuncPtr();
        }

    Do i have to change the SBLLIB_CORE_ID_MPU_CPU0 to SBLLIB_CORE_ID_DSP1 to start my application?

    Please give me some details/examples about this last point. This point is not part of the documantion. Also the examples for ARM A15 are returning Unsupported device! for all DRA7xx devices.

    regards

    Paul

     

  • Hi,

    i found my mistake. I don't need a conversion of the bin file into a tiimage. The bin file after the MulticoreImageGen.exe is the final AppImage.

    Now the code is successful loaded with a seperate entry point adressing inside the cfg file:

    Program.sectMap[".init { boot*(.text) }"] = new Program.SectionSpec();
    Program.sectMap[".init { boot*(.text) }"].loadAddress = 0x80031EC0;

    This line of code gives me the ENTRY POINT SYMBOL: "_c_int00" address: 80032000.

    For now my app image is loaded, but not running on the DSP1. I only gets the following returning "Putting MPU in Retention...". My App image includes the my app binary for DSP1, only. Is this correct? Or do i need a start up code for the CPU0? Or is it nessesary to change the sbl_tda2ex_main.c file in line 457?

    /* Jump to MPU CPU0's entry point */
    if (0U != sblEntryPoints.entryPoint[SBLLIB_CORE_ID_MPU_CPU0])
    {
    SBLLibPrintf(SBLLIB_TRACE_LEVEL_IMP_INFO,
    "\n Jumping to MPU CPU0 App \n");
    UARTWaitUntilTransmitComplete();
    mpuCore0EntryFuncPtr =
    (EntryFuncPtr_t) (sblEntryPoints.entryPoint[
    SBLLIB_CORE_ID_MPU_CPU0]);
    mpuCore0EntryFuncPtr();
    }

    Do i have to change the SBLLIB_CORE_ID_MPU_CPU0 to SBLLIB_CORE_ID_DSP1 to start my application?

    Please give me some details/examples about this last point. This point is not part of the documantion. Also the examples for ARM A15 are returning Unsupported device! for all DRA7xx devices.

    regards

    Paul
  • Hi Paul,

    SBL parses the multicore app image and identifies the entry point for different cores. If any core's app image is not part of multicore app image the entry point will be 0x0 for that core. SBL puts such cores into low power state (retention in case of MPU). What is the value of sblEntryPoints.entryPoint[SBLLIB_CORE_ID_DSP1]? It should be _c_int00 i.e. 80032000 as per your explanation.

    Also can you elaborate on the point "ARM A15 are returning Unsupported device!".

    Thanks & Regards,

    Rishabh

  • Hi,

    i modified the sbl source code for SBLLIB_CORE_ID_DSP1 and i get exactly the right entry point address from sblEntryPoints.entryPoint[SBLLIB_CORE_ID_DSP1] back. So the entry point address is now 0x80032000 and the SBL is jumping to this entry point.

    But the code doesn't start or doesn't execute my application, becuase i don't get the uart return values from my application. Do i have to enable the dsp1 first with the A15 master unit?

    And the "Unsupported device!" issue is inside the examples of the TI Resource Explorer. I load the hello world example for A15 (DRA72x) and do an import to my workspace. After this step i build the code and get the "Unsupported device!" error.

    regards

    Paul

  • Hi Paul,

    SBL(running on A15) boots DSP by passing it the entry point through control module register.
    As this is DSP app's entry point SBL won't jump there rather DSP will start execution from there.
    After SBL boots all the slave cores it will print its timing statistics.
    If DSP doesn't wait for SBL to finish and try to print something on UART it might lead to wrong UART output.

    Can you try to connect to DSP using CCS after the boot and see its state.

    Regards,
    Rishabh
  • Hi,

    i did a connection to the DSP1 with CCS after the SBL boot and the DSP is stopping inside the system initialisiation before main function.

    The DSP doesn't execute my main function and is in an freezing state.

    Whats wrong on my side?

    Should i have to execute some code on the master cpu first? If this is correct, can you send me an example for that master cpu application. Or is my SBL modification wrong?

    best regards

    Paul

  • Hi Paul,

    System initialization function depends on the DSP cfg file. SBL modification seems fine as the application has started.
    Can you try the DSP cfg file from Vision SDK(www.ti.com/.../PROCESSOR-SDK-TDAX). If it still doesn't work for you kindly share the DSP application's cfg file.

    Regards,
    Rishabh

  • Hi Rishabh,

    can you send my the link again, because the link doesn't work.

    I also find a information about the DSP Boot address alignment inside the SBL_User_Guide.pdf (See chapter 13 page 22).

    This is telling the following:

    "Boot address for the DSP Core should be aligned to ‘0x400’ boundary. When the SBL brings DSP core out of reset it can load only the higher order 22 bits of the boot address and the lower order 10 bits are expected to be 0."

    I aligned my DSP Boot address to '0x800' boundary. Maybe this isn't correct. I tried now to include the example from the "SBL_User_Guide.pdf" to my .cfg file, but i can't include the memory segment DSP1_PROG.

    But first i will try the .cfg file from teh Vision SDK.

    Regards,
    Paul

  • Hi Paul,

    the link is:
    www.ti.com/.../PROCESSOR-SDK-TDAX

    (the forum engine included the bracket as part of the link in Rishabh's post)

    Regards,
    Yordan
  • Hi Paul,

    The SBL user guide describes two different methods of doing code alignment. The first method is used when linker command file is used to specify the memory map (typically no OS build without BIOS/XDC). The second method is for BIOS build.

    The same code is part of Vision SDK Dsp1.cfg file:

    /* Boot address needs to be aligned to 0x400 */
    Program.sectMap[".text:_c_int00"]             = new Program.SectionSpec();
    Program.sectMap[".text:_c_int00"].loadSegment = "DSP1_CODE_MEM";
    Program.sectMap[".text:_c_int00"].loadAlign   = 0x400;

    Regards,

    Rishabh

  • MyProjectSysBiosConfig.cfg

    Hello,

    i did all steps from the SBL_user_guide.pdf, but it isn't working. In one of my previous post, i ask you a question about the master cpu.

    I create my AppImage für the SD card with the following way:

    out2rprc my_project.out my_project.rprc

    MulticoreImageGen.exe LE 66 AppImage_LE 8 my_project.rprc

    And here you can see, i have only a dsp source code file. Do i need a  startup code for the master cpu?

    My .cfg is the attached.

    best regards Paul

  • Hi Paul,

    Have you renamed AppImage_LE to AppImage?
    Also can you share the SBL boot log.

    Regards,
    Rishabh
  • Attachment.7z

    Hi Rishabh,

    yes i renamed the Multi App Image. The SD card has only the MLO and the AppImage inside.

    I attached my modified SBL .c file, the compiled MLO for SD Boot and the SBL log.

    I did all steps from the SBL_User_Guide and it isn't working. The only difference is, that i modified the default SBL for DSP boot. Because i have a source code for the DSP only. All the other cpus don't have a source code in my workaround.

    Do i need other source/startup code for the master cpu or the other internal controllers?

    Regards

    Paul

  • Hi Paul,

    I saw your changes. The issue is with the way you have modified the SBL main.

    DSP1 comes out of reset when you call SBLLibDSP1BringUp.

    With your change A15 jumps to entry point of DSP.

    You should keep the SBL main as is. In DSP application add a wait at beginning of main so that DSP is idle until SBL finishes. This will prevent DSP from using resources like EDMA, UART, etc. which can be accessed by SBL even after DSP1 bring up.

    Regards,

    Rishabh

  • Thanks for your reply.

    I did now a revert of the sbl file to the default one and recompiled it. Now i have the default MLO for the SD card. Also i included a sleep loop in the main(void) (around 6sec) of my DSP source code.

    The SBL log looks like this:

     TDA2Ex SBL Boot

     DPLL Configuration Completed

     Clock Domain Configuration Completed

     Module Enable Configuration Completed

     TI EVM PAD Config Completed

     DDR Config Completed

     App Image Download Begins

     SD Boot - file open completed successfully

     DSP1 Image Load Completed

     App Image Download Completed

    *****************************************************************

     PMCCNTR counts once every 64 clock cycles, multiple by 64 to get actual CPU cycles

      - 71289  (1076887816.1 ms)
      - 179985  (1076887816.1 ms)
      - 45880  (1076887816.1 ms)
      - 1215259  (1076887816.1 ms)
      - 14102  (1076887816.1 ms)
      - 1527605  (1076887816.1 ms)
      - 14772  (1076887816.1 ms)
    *****************************************************************

     Putting MPU in Retention...

    My programm doesn't start after the 6 sec. I also executed my program via JTAG and it runs fine. I expect a print on UART only. But the UART terminal is showing me the SBL log only. And after a few second (around 1min) the SBL is restarting or running into a cpu reset.

    Do i have to wait longer than 6 sec? Or less than 6 sec?

    Is this mode correct "Putting MPU in Retention..." for DSP boot up?

    regards

    Paul

  • Hi Paul,

    SBL parses the application image and puts all the cores in low power state for which it doesn't find an image.
    So A15 putting MPU (i.e. itself) to retention is not a problem.
    Can you change the DSP application to write a particular pattern at an OCMC location instead of UART print and see if it works.

    Regards,
    Rishabh
  • Hi Paul,

    Also SBL must be restarting after 3 minutes. This is the watchdog reset (timeout set by RBL).
    Application should either disable the watchdog or handle it.

    Regards,
    Rishabh

  • Hi Risbabh,

    i forgot some information about the debuging state that i did, too.

    After the SBL start up, i activated the JTAG. The program is always inside the I2C Master Busy State. That means my programm is always inside the cint routine.

    How can i fix this? Is this a .cfg issue?

    Regards

    Paul

  • Hi Paul,

    I did not understand how DSP is in I2C Master Busy State? Is your application doing I2C programming.
    Can you share your dsp cfg file.

    Regards,
    Rishabh
  • Hi Rishabh,

    i am using for now the UART_BasicExample_evmDRA72x_c66xExampleProject from the pdk library.

    But this is also not working. I included 6sec at the beginning of the main function. And if i look inside, the controller is always an this address:

    800471c0    00000020                 : i2c.oe66 (.text:I2CMasterBusBusy)

    I send you the .out file and the example project. I tried a lot, but my output is always the same. The application doesn't start and is running all the time into the I2CMasterBusBusy.

    For my main project i need the i2c, because i have to enable the ac31x codec on the EVM. How can i fix the I2CMasterBusBusy issue and get my application to work?

    best regards

    Paul

    uart_BasicExp_for_evmDRA72x_c66x.7z

  • hi Rishabh,

    i spent some time for the sbl again. And i found out, that the sbl utils is using i2c. I think thats the issue, why my programm is stopping inside the i2cMasterBusBusy state.

    Is there a issue inside the SBL boot?

    best regards

    Paul
  • Hi Paul,

    It seems something else is going wrong and SBL is loading application properly. I2C busy error might be happening due to some other reason.

    To debug this instead of wait, add a while loop

    volatile int wait=1;
    while(wait);

    Using CCS connect to DSP and then do a single step.

    Regards,

    Rishabh

  • Hi Paul,
    Issue is not with SBL. If you see PC is in DDR whereas SBL executes from OCMC RAM. Can you do a single step as suggested and check why I2C is giving bus busy.

    Regards,
    Rishabh
  • Hi,

    i managed the single step debugging with the while(1) loop. The application is inside the endless loop. Thats fine!

    After this step, i changed the loop to 25sec and did the single step debugging procedure again. The application is running into the 25sec loop, but after the loop the application is going into the I2CMasterBusBusy() state inside the Board_Init() function.

    Do you have some ideas why this is happening?

    And can you send me an example code for handling the watchdog sbl reset. Because i have to avoid the reset in my application.

    thanks

    Paul
  • Hi Paul,

    Your observation confirms that there is no issue in SBL. Is there a particular switch setting that is needed by board_init API?
    Can you try to see which particular lines of code lead to I2CMasterBusBusy() call.
    To disable watchdog timer call WDTIMERDisable(SOC_WD_TIMER_BASE) API.

    Regards,
    Rishabh
  • Hi Paul,

    In the original post, you mentioned you were using a custom application, so I didn't realize you had switched to using the PDK examples.  Also, I don't recall the device being J6Eco and I had assumed you were using J6.  I apologize for all of the excursions here, but I now understand the issue you are facing with the I2C.

    The pad configuration sequence in the SBL conflicts with some of the board initialization done in the PDK examples which are supported out-of-box through CCS loading.  In particular, the I2C5 pads are not accessible after the SBL pad configuration, but the PDK board library tries to write to an I/O expander device on this bus, so it will hang indefinitely.  There is a tweak required in order to get this particular example running.  You can select one of any of these options:

    1. Adjust the pad configuration for CTRL_CORE_PAD_MCASP1_AXR0 and CTRL_CORE_PAD_MCASP1_AXR1 in sbl_utils for SOC_TDA2EX to select I2C5_SDA and I2C5_SCL, respectively.
    2. Comment out the Board_ioexpConfig function in the PDK board library (I/O expanders don't affect this example)
    3. Comment out use of I2C5 in Board_ioexpConfig (which uses 0-indexing and will look like you are using instance #4).  This particular expander only affects the McASP example application

    The easiest would be 2 or 3 as a test, but 1 is the correct sequence when getting the application to a more production-ready state, and in particular 1 will be required if your application needs to access I2C5.

    Also, please keep in mind all of Rishabh's feedback as useful reminders on the other issues faces (thanks, Rishabh!).

    Let me know if you are able to get this running.  Then we can take a look at what else you need to do in particular for your application, if necessary.

    Thanks,
    Stephen

  • Hi Stephen,

    thanks for your helpfull reply, i got a success. The UART_example from the pdk is running with option 2.

    Now i would like to switch back to my custom application with audio in and out support. In this application i use the McASP and the AC31x Codec.

    Like you said, my custom applictaion with McASP support doesn't work well with option 2 and 3. My application is based on the McASP Echo Demo from the pdk.

    Can you tell me the modification for option 1 in detail, please. I tried some modifications, but it didn't work for me. Inside the sbl_utils_tda2xx.c, i found the gModuleEnableTable. Do i have to exclude all of the PMHAL_PRCM_MOD_I2Cx from them?

    We are on a good way to get my application to work :)

    best regards

    Paul

  • Hi Paul,

    Really glad to hear that this has worked for you!

    Yes, you're right that in order to get the PDK Audio Loopback example working, we need to explore option 1 I listed previously.  There are two modifications to the SBL needed to enable this application:

    1. Modify the gModuleEnableTable in sbl_utils_tda2xx.c, as you mentioned.  You don't need to exclude anything, but you will need to add an entry 
          {PMHAL_PRCM_MOD_I2C5,        PMHAL_PRCM_MODULE_MODE_ENABLED, "I2C5"},
      

      This is currently done for SOC_TDA2PX but will need to be added to enable this module on J6Eco (you can probably just remove the ifdef around this entry)

    2. Modify the gPadDelayConfigCommon* tables surrounded by the '#elif defined (SOC_TDA2EX)' in sbl_utils_tda2xx_iodelay.c.  Depending on which silicon revision you have, you will either need to modify the _1_0 table for SR 1.0 or _2_0 table for SR 2.0.  If you're not sure which you have, you can be safe in modifying both.  You will need to I2C5 SDA/SCL signals (via McASP1 AXR0 and AXR1) and McASP3 ACLKX, FSX, AXR0, and AXR1.  
          /* Enable I2C5 */
          {0x2B4,  0x6000A,
            {0x0,    0,         0}, {0x0, 0, 0}, {0x0,    0,    0}},
          /** {CTRL_CORE_PAD_MCASP1_AXR0, 0xC0107, {N/A}, {N/A}, {N/A}} **/
          {0x2B8,  0x6000A,
            {0x0,    0,         0}, {0x0, 0, 0}, {0x0,    0,    0}},
          /** {CTRL_CORE_PAD_MCASP1_AXR1, 0xC0107, {N/A}, {N/A}, {N/A}} **/
      ...
          /* Enable McASP3 */
          {0x324,  0x40000,
            {0x0,    0,         0}, {0x0, 0, 0}, {0x0,    0,    0}},
          /** {CTRL_CORE_PAD_MCASP3_ACLKX, 0x40107, {N/A}, {N/A}, {N/A}} **/
          {0x328,  0xC0000,
            {0x0,    0,         0}, {0x0, 0, 0}, {0x0,    0,    0}},
          /** {CTRL_CORE_PAD_MCASP3_FSX, 0xC0107, {N/A}, {N/A}, {N/A}} **/
          {0x32C,  0xC0000,
            {0x0,    0,         0}, {0x0, 0, 0}, {0x0,    0,    0}},
          /** {CTRL_CORE_PAD_MCASP3_AXR0, 0xC0107, {N/A}, {N/A}, {N/A}} **/
          {0x330,  0xC0000,
            {0x0,    0,         0}, {0x0, 0, 0}, {0x0,    0,    0}},
          /** {CTRL_CORE_PAD_MCASP3_AXR1, 0xC0107, {N/A}, {N/A}, {N/A}} **/

    Once you rebuild the SBL, this should enable the application to access I2C5 to program the I/O expander (you will need to revert your PDK board changes to re-enable this) and McASP3 for the audio signals on the EVM, in addition to I2C1 for the AIC3106, which was already enabled with the default SBL configuration.

    If this is done properly, you should be able to play audio through line-in and listen through line-out.  Preferably the output should go to a set of speakers, but headphones should work as well though with a weaker output signal.

    Thanks,
    Stephen

  • Thanks Stephen and Rishabh,

    the SBL and my custom programm is starting with the I2C5 patch. It is very hard to understand the RTOS functionality in combination with SBL.

    Now my main issue from this thread is done :)

    One last thing. In the last days, i wrote a qspi flash reader. This based on the "main_qspi_flash_read_write.c" example from the pdk.

    Now my issue is, it is working in JTAG debugging mode but not with SBL. Is there also a similiar conflict with the QSPI and the SBL? The QSPI_Init should be fine, but the QSPI_Read function is running into Idle state all the time.

    best regards

    Paul

  • Hi Paul,

    Good to hear the application is working now as expected!

    I'm not sure about the QSPI flash reader program. I reviewed the SBL and Board library and there doesn't seem to be any configuration conflict with respect to the pad configuration.

    Can you clarify where your program is hanging? There is no call to QSPI_Read in this application, but SPI_transfer will eventually map to a lower-level read command, which depending on the QSPI mode (CFG or MMAP) may operate differently. Can you confirm your QSPI settings match the original settings from the example, or explain what you have modified?

    Thanks,
    Stephen
  • Hi Stephen,

    the clarification is not that easy. Sometimes the programm is hanging indide the Idle task of the BIOS, sometimes it is hanging somewhere inside the HWI or inside the timer. It is realy difficult to debug that thing.

    Without the SBL, if i load the application with the JTAG, i can run my QSPI_Read function. But sometimes i get strange issues with the JTAG, too.

    My QSPI Flash Reader contains the same functions from the "main_qspi_flash_read_write.c" file. I did only a rearrangement of the example to get my usage to work. The init and the read function for S25FL256 flash and all settings are the same from the example.

    regards

    Paul

  • Paul,

    It sounds like your task is in a blocked state. You can confirm this by looking at the Tools -> RTOS Object View (ROV), selecting the Task module and looking at either the Detailed or CallStacks view, and it should tell you what the reason for the block is.

    Assuming it's a semaphore, it could be because the driver is requesting a transfer but the transfer completion interrupt isn't coming through. Do you have the interrupt crossbar configured properly in your modified application?

    If not the semaphore, let me know if you can find any information from ROV on what may be causing the scheduler to be off in the weeds somewhere.

    Thanks,
    Stephen