TM4C1294NCPDT: RTOS: BIOS not working

Hello Deepak,

The address 0x00078100 is very unusual, can you give some context here about why that address? I would expect it to start at 0x78000 which is the start of that Flash block. My suspicion is this would be the problem here.

Can you first try the application at 0x4000 to see if it works there? That's the typical application location for a program using TM4C129x boot loader.

By the way you may find this post useful regarding how to create the boot loader and adjust your files: https://e2e.ti.com/support/legacy_forums/embedded/tirtos/f/ti-rtos-forum-read-only-archived/574584/rtos-ek-tm4c1294xl-custom-spi-bootloader-ti-rtos-problem---tiva-c-tm4c1294/2116161#2116161

Best Regards,

Ralph Jacobi

Hey Ralph,

My bootloader is 32KB i.e. 0x8000

Then I have a Application partition A at 0x8100 as I have a header of 0x100 at 0x8000.

Application Part B starts at 0x78100 as that also has a header of 0x100.

Now, in my bootloader i'm able to execute the vector table to get the start address for application A and B depending on which I need to boot from.

As I boot from App A or App B, after I get into function BIOS_start();  my code hangs and there's no update after that.

My question is do we need any setting for BIOS to work? 

And also I tried your suggestion for 0x78000 and still the same result. Also same result at 0x8000

Regards,

Deepak

Hello Deepak,

Deepak Rai said:

My question is do we need any setting for BIOS to work? 

My understanding of the BIOS is reasonably limited so I don't really have an answer. I will discuss with my colleague tomorrow to see if we can provide some guidance.

In the meantime, I would recommend you review the post I shared above.

If your boot loader is 32kB, does that mean you made a custom boot loader and are not using TivaWare boot loader?

Best Regards,

Ralph Jacobi

Ralph Jacobi said:

The address 0x00078100 is very unusual, can you give some context here about why that address?

Section 2.5.4 Vector Table of the TM4C1294NCPDT datasheet says:

On system reset, the vector table is fixed at address 0x0000.0000. Privileged software can write to the Vector Table Offset (VTABLE) register to relocate the vector table start address to a different memory location, in the range 0x0000.0400 to 0x3FFF.FC00 (see “Vector Table” on page 119). Note that when configuring the VTABLE register, the offset must be aligned on a 1024-byte boundary.

If SYS/BIOS uses the value of m3Hwi.resetVectorAddress to set the VTABLE register, using an address with incorrect alignment could cause an issue.

Hi Chester,

Yes, I was thinking along those lines... I haven't been able to verify that, but I do think that may part of the issue. Unfortunately adjusting that alone did not fix it for Deepak.

That said, Deepak, as we continue to debug for now please us 0x78000 and 0x8000. Once we get that working, then you can try and shift it to see if that causes an issue.

Best Regards,

Ralph Jacobi

Hi Deepak,

Can you load the RTOS application 0x0000.0000 to check it BIOS_start() is working without boot loader? 

Oddly CCS debug with boot loader installed may crash when jumping reset vector (_c_INT00) looking for main.c. Perhaps remove main.c debug settings allows boot loader functions and view m3Hwi fault stack via (RunTimeObjectView) located under tools. Dual boot may be a difficult to achieve from boot loader especially with RTOS. 

Hi GI,

RTOS application works fine without the bootloader if the application is at 0x00.

That is the thing I'm not getting. When application is at 0x8000 and I'm using CCS debug, it works fine and code runs correctly and I can see that code is at 0x8000 using memory read. but when I restart my board it doesn't work

Bootloader is correctly pointing to where to start from, I'm able to do all the initialization but BIOS doesn't work. I'm thinking there's some BIOS setting in .cfg file to let it know that application has moved to other location.

Regards,

Deepak

Deepak Rai said:

RTOS application works fine without the bootloader if the application is at 0x00.

Which peripheral(s) does the bootloader use, and do the peripheral(s) get reset before the application is used?

I'm trying to set up an Ethernet example based upon TI-RTOS for TivaC 2.16.0.08 so can try moving the start address.

Ralph,

Yes, I'm using a custom bootloader.

Chester,

I'm reseting all the peripherals that i'm using like watchdog, interrupts, systic etc.

I don't think my bootloader has anything wrong as I already use the same bootloader for a different project and that works fine. The other project is bare-metal and i have not seen any issues. It is also based on same principle of flash memory division for bootloader, part A and Part B.

Regards,

Deepak

Deepak Rai said:

When application is at 0x8000

You mean the application FLASH origin address was being changed inside tm4cxx.cmd file to be 0x8000, not just inside bl_config.h?

I don't see why the need to change m3Hwi start address since the restart jump instruction should locate vector table 0x8000. Perhaps try to reducing the total FLASH length by the start address amount for m3Hwi to adjust for reading VTABLE register.

Hey Chester,

First of all, thank you so  much for the example code. I did some premutation and combination to test my code. I was able to exclude my application code from the issue. the instructions that you have used are the same that I have in my application code.

After that I was able to run my application code with your sample bootloader. There after I started debugging my bootloader code and I was able to figure out why my BIOS wasn't running if I'm using my bootloader.

In my bootloader, I'm using watchdog, systic, serial etc and for that I have used this instruction

MAP_IntMasterEnable();

I'm also disabling it by using 

MAP_IntMasterDisable();

and when I have this in my bootloader code, my BIOS doesn't load in application code.

After I removed these instructions, my code works fine.

Any idea why this is causing issue with BIOS?

Regards,

Deepak

Deepak Rai said:

In my bootloader, I'm using watchdog, systic, serial etc and for that I have used this instruction

MAP_IntMasterEnable();

I'm also disabling it by using 

MAP_IntMasterDisable();

and when I have this in my bootloader code, my BIOS doesn't load in application code.

I just added the calls to MAP_IntMasterEnable() and MAP_IntMasterDisable() into my simple bootloader without actually using any interrupts:

    UARTConfigSetExpClk(UART0_BASE, SysClock, 115200,
                        UART_CONFIG_WLEN_8 | UART_CONFIG_STOP_ONE | UART_CONFIG_PAR_NONE);

    MAP_IntMasterEnable ();
    MAP_IntMasterDisable ();

    /* Report that the bootloader is running */

The project didn't enable the ROM mapping, so ended up calling IntMasterEnable() and IntMasterDisable() in flash.

That was sufficient to break my test tcpEcho application which is now failing to get a DHCP address which matches the failure you originally reported:

Bootloader running
Transfering to application with SP=0x2000f648 PC=0x00014fc5
Using MAC address in flash
Starting the TCP Echo example
&ti_sysbios_family_arm_m3_Hwi_resetVectors=0x8100
Service Status: DHCPC    : Enabled  :          : 000
Service Status: DHCPC    : Enabled  : Running  : 000

Will try and determine the cause.

Chester,

On further analysis, I can conclude that the disable instruction is breaking the code. If you keep the enable instruction and remove the disable instruction, the code works fine.

Regards,

Deepak

Hi Chester & Deepak,

Yes that would be the big difference here. PRIMASK is zero by default so by removing both lines OR leaving MAP_IntMasterEnable(); in the code without the disable, PRIMASK will be zero when SYS/BIOS starts.

Depending what you need from the boot loader or application, MAP_IntMasterEnable(); could be a call made right before exiting to the application code in the boot loader or it could be before the BIOS is started in the application code.

Best Regards,

Ralph Jacobi

Thank you Ralph & Chester for all your help.

I'll try to test my code by keeping just the enable instruction in bootloader or add a call in application and see if it causes any issues as I'm not sure if that will be a problem or not.

Regards,

Deepak