• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 100 subscribers
  • Views 2247 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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/TI-RTOS: AM335x very slow application start

JimFr
Intellectual 305 points

Part Number: TI-RTOS

Tool/software: TI-RTOS

Hi there,

I am using the Bootloader located in the starterware folder of pdk_am335x_1_0_7 and running a simple rtos application from SPI Flash on my phycoreAm335x SOM. 

After the image load to RAM it takes about then seconds to reach the GPIO_Toggle function at the beginning of my code which lits a LED, while within a debugging session the application runs instantly and the LED turns on...

Is there sth. to consider in the case of using the bootloader with a rtos application?

Codesnippet:

int main()
{

/* Call board init functions */
Board_initCfg boardCfg;
boardCfg = BOARD_INIT_PINMUX_CONFIG |
BOARD_INIT_MODULE_CLOCK;// | BOARD_INIT_UART_STDIO;
//boardCfg = BOARD_INIT_ALL;


Board_init(boardCfg);
//Network_init();
GPIO_init();
GPIO_toggle(USER_LED0); //ten seconds till the LED is lit...

...

BIOS_start();

return -1;
}

Regards,

Jim

  • 0
    TI__Guru**** 393215 points
    The RTOS team have been notified. They will respond here.
  • 0
    TI__Guru** 116770 points

     Please note that the bootloader does the pinmux config and clock config so, you shouldn`t need that in your application code. Can you put a while loop before GPIO_init so that the core halts on the while and you can connect to the ARM core. Then step through the GPIO_init and GPIO_toggle to see what is consuming bulk of the ten seconds

    Are you sure it is the application that consumes 10 seconds. I tried this on the AM335x ICE board and did not run into this issue. but SPI and MMC are the the first and the second boot modes in the boot sequence on those boards. One of the primary reasons we have seen this in the past is if the SPI is not the first boot media in the boot sequence and if there is a peripharal boot mode like Ethernet, USB or UART ahead of SPI in the boot sequence.If peripheral boots are in the boot sequence the RBL waits for those to time out before it proceeds to the next boot mode. Please refer to the initialization chapter and check the boot sequence corresponding to the bootmode pins on the PHYtec board.

    Regards,
    Rahul

  • 0 in reply to Rahul Prabhu
    Intellectual 305 points
    Hi there,

    I am going to start a deeper debug session and will reply here. Thank you for your fast response, i appreciate your help.

    Regards,

    Jim
  • 0 in reply to JimFr
    Intellectual 305 points
    Hi there,

    i just startet to work on this problem and was wondering where in the bootloader the pinmux is done. I found the clock and device configuration but nothin about the pinmux. Would you mind giving me some informations about pinmuxing in the bootlaoder. For me the documentation of the bootloader is very confusing (if available).

    Regards
  • 0 in reply to JimFr
    Intellectual 305 points
    Hi,

    I did a small pinmux and wrote a very basic rtos project which only toggles a pin which is allready configured in the bootloader config and is used there to benchmark the boottime (gpio 0). I excluded all clock and other initialisations from the rtos application and moved/checked the necessary options in the bootloader. The Pin ist toggled but still after about 10 seconds later...

    Regards Jim
  • 0 in reply to JimFr
    Intellectual 955 points

    Jim,

    I also am using the same phytec board and trying to boot my TI-RTOS application from SPI flash.  It works but is way too slow.  The problem is not in the RTOS, but in trying to get the bootloader to run the SPI efficiently.

    There are 2 stages here.  I have the AM335x boot word set up to boot my loader from SPI flash first.  I scoped the transfers to see how the internal loader is running the SPI.  It is doing 32-bit transfers in about 2.6us each, with a gap of 1.8us between transfers.  My SPI boot loader is about 36k and loads from flash in about 38ms by the internal boot ROM code.  This defines what should be possible. It would be useful if TI could tell us whether the internal SPI booter is set up for 32 bit words, or is using 4-byte FIFO transfers, and whether or not they are using the DMA controller. Or something else.

    My boot loader is derived from the Starterware example.  The performance I get is a byte transfer at 300ns, followed by an 8us gap in between byte transfers. This makes my 3.3MB RTOS application take almost 20 seconds to load.  And also makes data retrieval from flash by my application somewhat slow, as it uses the same driver for the SPI.

    I would really like to understand how to configure the SPI to read efficiently using its internal FIFOs to cut down the gaps, without using DMA.

    As an aside, I do use DMA to move data from memory to my application specific SPI hardware, and that works well enough.

    Gerry Belanger

  • 0 in reply to Rahul Prabhu
    Intellectual 305 points
    Hi Rahul,

    I think i had some workspace issues. After importing the project into a new workspace it is loaded in no time.

    Thanks and regards,

    Jim