SYSBIOS: PRU firmware load error

Hi Han,

You may search 'llEnter: Illegal priority call to llEnter()' in the forum, some answers may help, e.g

Regards,

Garrett

Thanks for you response Garrett !

I have already done a search for the "llEnter: Illegal priority" phrase and the posts that I have read all seem to point to tasks with a priority higher than the maximum priority allowed.

However, I think my problem is different from a simple task priority error. What I described in my problem description is that I start from a working source code base and in baby steps add functionality for the PRUs. In the last step that I do, I have nearly all PRU functionality in my software and when I run my software, it is still working without the error. But when I turn off my device, then turn it back on again and try to run the exact same binary image, I all of a suden get the error message. So the only change it the hardware reset of the device and this causes the error. Note: During the adding of the PRU functionality, I never power cycled the device, I just loaded the software using the JTAG debugger and ran it.

When I power cycle the device with my 'starting point' software, there is never a problem running the software (we have already performed some qualification tests on our hardware, where the device is reset a lot for changing the setup and this is done without any problems).

From my point of view, there might be something initialised in memory that keeps the software running while I add functionality, but as soon as I reset the device, this 'data' is no longer in memory and somehow causes the 'illegal priority' error.

Today I will start working backwards, until I get back to a functioning software again, so that I have an idea where I should look for the fault. When I have more information, I will post it here.

Kind regards,

Han

Additional information after slowly changing back the code from the fault situation to a situation where my software is working again:

The error:

00000.500 llEnter: Illegal priority call to llEnter()

00000.507 llExit: Illegal call to llExit()

Seems to be caused by the flag BOARD_INIT_ICSS_PINMUX, which is passed by my application to the function 'Board_init'. The code for the 'Board_init' looks as follows:

----------------------------------------------------

    Board_initCfg   boardCfg;
    Board_STATUS    boardStatus;

    boardCfg = BOARD_INIT_PLL | BOARD_INIT_DDR | BOARD_INIT_PINMUX_CONFIG | BOARD_INIT_MODULE_CLOCK |
                BOARD_INIT_ETH_PHY /*| BOARD_INIT_ICSS_PINMUX | BOARD_INIT_ICSS_ETH_PHY*/;
    boardStatus = Board_init (boardCfg);
    if (boardStatus == BOARD_SOK)
    {

----------------------------------------------------

When I run this, my application works fine. If I uncomment only the 'BOARD_INIT_ICSS_PINMUX' flag and leave the 'BOARD_INIT_ICSS_ETH_PHY' commented out, there are 2 possible results of running my code:

1. When I re-build the software, don't reset my board and load my image into the target, the software will run perfectly.

2. When I re-build the software, perform a hardware reset of my board and then load my image, I get the priority related error message

So it seems that it matters if I first run a working version of my software or that I start with a board that has just been reset for the code with the init flag 'BOARD_INIT_ICSS_PINMUX' to work or not. The code that gets called because of the 'BOARD_INIT_ICSS_PINMUX' flag is exactly the same for my board as for the AM3359 ICE V2 board.

The only thing I can think of causing this problem is an issue with my Pinmux file. The Pinmux I use is created using the online Pinmux tool. I will have a look at it in detail to see if there is an issue with it. But I think it is a bit strange that an issue with the Pinmux can cause this kind of errors.

So my new question is, how could the use of the flag 'BOARD_INIT_ICSS_PINMUX' cause the error with the illegal priority ?

Kind regards,

   Han

Han,

If you look into the Board_init() function, BOARD_INIT_ICSS_PINMUX has to be kept for the board pinmuxConfig.

if (cfg & BOARD_INIT_ICSS_PINMUX)
{
icssPinMuxFlag = 1U;
ret = Board_pinmuxConfig();

}

Yes, you have to look into your pinmux file more carefully. Without an incorrect pinmux file, any weird thing may happen.

As you are working with a custom board, did you re-build the board library and step into the Board_init() function to ensure all peripherals are activated as designed? 

Regards,
Garrett

I have some more information.

What I have done is try the TI project 'NIMU_ICSS_FtpExample_icev2AM335x_wSoCLib_armExampleproject' with my board definition. This did not give me the 'priority' error. I also checked my pinmux file with respect to the PRU pinmux against the pinmux file of the TI ICE V2 board and I could not find anything that would cause errors. The pins I use are defined the same as for the TI ICE V2 boad, I only have a few pins less, like the UART pins.

Next I studied the source code of the NDK in more detail, to see what could be the problem. llEnter increases the current priority to 'OS_TASKPRIKERN' and compares it to the priority returned by 'TaskSetPri', so I started to look in that direction. My application .cfg file sets the priority for the NDK kernel task priority to 15 (Global.kernTaskPriLevel = 15) and I checked that it is actually set to 15 using the calls to 'CfgGetEntry' and 'CfgEntryGetData', which showed that it was really set to 15. So that should be fine, because there is no other task running at or above priority 15, which I checked by listing all tasks known in the system.

My next step was to modify the function 'llEnter' and make it print the priority level that was wrong according to the if statement:

if( tmpOldPriority >= OS_TASKPRIKERN )

When teh error occurred, this showed that 'tmpOldPriority' was 9 and 'OS_TASKPRIKERN' was also 9.

So here is my problem, somehow the 'OS_TASKPRIKERN' is wrong, maybe only in the beginning, I don't know. But it does not match the setting in my .cfg file.

In the .c file generated by the XDCTOOL, I can see the following code:

/* add the configuration settings for NDK kernel priority task level. */
rc = 15;
CfgAddEntry(hCfg, CFGTAG_OS, CFGITEM_OS_TASKPRIKERN,
             CFG_ADDMODE_UNIQUE, sizeof(uint32_t), (unsigned char *)&rc, 0 );

So the setting from my .cfg file is set in the NDK stack configuration. Later I discovered that 9 is the initial value for the priority.

My question now is, is it possible that updating this setting in the NDK stack settings is somehow delayed, so that it is running for sometime with the initial value for the setting ?

Would it be better to #define the option 'USE_LL_SEMAPHORE', so that I don't have this dependency on priority levels anymore ?

Is the only drawback that using the Semaphore is a little slower than the priority switching ? Or are there other issues ?

Please let me know what you think.
Kind regards,
   Han Hoekstra