TM4C1290NCPDT: Problem with RTOS task firing when base application address is changed.

Hi Jacobi,

First off I really appreciate the response. I like your idea. While it very well could be true, it would be odd as this is the same structure that is used for other correctly working firmware on other TI chips we have (same addresses, bootloader, etc. different application though). I would think if that was the problem here, we would see it everywhere. I will still try this though.

Some new things I have noticed. When the binary is loaded at 0x00, everything runs as expected. When loaded at our custom address, when I step through the code, everything seems initialized correctly (using RTOS object viewer) however nothing ever changes. Upon further inspection, the code is running the Idle task indefinitely. Which once again seems like maybe an interrupt issue, as if nothing is changing the flow from the idle task.

However the HWI in ROV looks the exact same as the list when it is working.

One curious thing I noticed is we have our halHwi.checkStackFlag = true in our RTOS config. Every so often, the flow breaks off from the idle task to run ti_sysbios_hal_HWI_checkstack() and it seems to be indicating there is an overflow every time.

Stack size in the picture is 2048 and I have tried increasing to 4096 with no success. I doubt the stack size is the actual problem, once again as the same configuration works at 0x00. Does this finding raise any antennas? I'm assuming the HWI stack overflow would certainly mess up HWI functionality and therefore timing/callbacks.

Once again, thank you for the help.

Ralph Jacobi said:

If you really can't set the application to be at 0x44000, then you will need to set it to load into and start at 0x48000. I believe that should resolve your problem.

TM4C1294NCPDT: RTOS: BIOS not working was a different investigation which showed TI-RTOS working with a m3Hwi.resetVectorAddress of 0x8100 which only has 256 byte alignment.

Mike Ford said:

Is there something that the RTOS, clock, or interrupts take for granted when at 0x00 that needs to be set or configured when it is not at 0x00?

Does the bootstrap use interrupts, or any of the peripherals which the application uses?

If so, what does the bootstrap do before calling the application?

Just try to rule out the change of m3Hwi.resetVectorAddress as being the issue.

In the thread referenced above one issue found was that if the boot loader called IntMasterDisable() prior to starting the application, the SYS/BIOS application will start with all interrupts disabled which is different to the the initial state on a processor reset.

Hi Mike,

I'll be honest that these kind of advanced RTOS topics are difficult to help with because our teams knowledge is centered heavily on the TM4C hardware itself in terms of peripherals etc. so when it comes to elements of the RTOS that are more BIOS related, we don't have a broad depth of knowledge to draw upon. You have been investigating for the root cause using all the right tools already. The stack overflow issue is certainly something I would imagine is impacting things, but I am not sure of the root cause yet. I will try and search for similar issues and see if I can find something of value that way.

In the meantime, Chester has better memory than I do and dug up a similar thread where he was able to help resolve the customers issue. I would recommend checking if the same situation might apply for your application.

Best Regards,

Ralph Jacobi

Hi Chester. Thank you for the thoughtful response.

First off, I agree with you're first point. I am aware of other firmware running on the same chipset using the same bootloader/flash address setup. Theoretically the only thing that is different is the application code itself. The wrapping bootloader and flash structure is the same. And I have seen other applications successfully run when loaded at a non page aligned address.

Unfortunately, this is somewhat a double edged sword because the bootloader is considered "golden" as it successfully loads and jumps to other TI-RTOS based firmware at the same address. Nevertheless, I went back and looked at the bootloader code and it does not do anything major such as disabling the interrupts. Essentially just minimal clock initialization, basic code verification (CRC), and then jump to code.

I realize what I've said above screams "application code problem", and I am not ruling that out. Being new to this firmware and TI-RTOS has been a lot to digest especially when facing a weird problem like this. I am going to look into the Idle loop/HWI overflow error I replied with above for now, as that seems like it would affect the clock module/timing ability to function properly. And somehow relate this to the address change since I don't see that error at 0x00. I'll also look at the linked thread for ideas.

In all honesty, this problem has been a great way to jump into learning TI-RTOS and refresh my low level memory skills :). Appreciate the feedback.

No worries Ralph I understand. These topics are complex and made even harder trying to convey the problem over forum posts :). I'll look through the posts and also keep digging, I get a little further each day. Thanks for the help!

Hi Mike,

I would look for either an IntMasterDisable call or a CPUcpsid in either your boot loader or inside of your application just prior to jumping to the boot loader.

I believe you have looked for the former in the boot loader already so maybe it is the later being called instead, but I think perhaps it is inside of the application itself that it is being called. It is not unusual to see someone call IntMasterDisable before jumping to the boot loader. 

Best Regards,

Ralph Jacobi

Hi Ralph. Thanks for the suggestion. Since this post I have discovered that PRIMASK is actually being set by our bootloader somewhere. It is still not clear where. We actually just got lucky that our firmware that "worked" did an enable interrupts call for an unrelated reason before the BIOS kicked off.

I think this will have to be the permanent "workaround" as the bootloader is used in many placed and would be complicated to update. Out of curiosity I am trying to figure out where the bootloader is setting PRIMASK. Like I said before it just does some basic oscillator setup. 

I do notice that we write to the SYSCTL_MISC and SYSCTL_RIS registers that have to deal with interrupts. But from the datasheet, I didn't see any bitfield in these registers that explicitly called out changing PRIMASK value as a result. Other than that it is a lot of RCC register writes, which doesn't seem like it would matter. The bootloader is not cooperating when trying to be step through debugged.

I think it's safe to say the original problem is solved, it is just continuing out of curiosity at this point. Thank you for your's and Chester's help.

Hi Mike,

Maybe you can do a blanket search across the source code for PRIMASK. Even the CPUcpsid API uses that for assembly code:

uint32_t
CPUcpsid(void)
{
    //
    // Read PRIMASK and disable interrupts.
    //
    __asm("    mrs     r0, PRIMASK\n"
          "    cpsid   i\n"
          "    bx      lr\n");

    //
    // The following keeps the compiler happy, because it wants to see a
    // return value from this function.  It will generate code to return
    // a zero.  However, the real return is the "bx lr" above, so the
    // return(0) is never executed and the function returns with the value
    // you expect in R0.
    //
    return(0);
}

Best Regards,

Ralph Jacobi