F28M35H52C: UART stops working after function call

Steven Buuck

Part Number: F28M35H52C
Other Parts Discussed in Thread: C2000WARE

I have been working on a project where I have added a bootloader on top of the M3 and C28 main programs. The problem I am having is when communicating via UART with another program on my computer.

Currently as it stands the M3 bootloader starts and waits for some time to receive a command via UART from the outside program or times out and jumps over to the other loaded main program via function pointer

When the M3 bootloader receives the command it enters a conditional and responds to the outside program via UART

This part all works fine

Then some functions are moved to execute from RAM via memcpy and a function call to load a new main program

Once entered the function call, UART no longer outputs to the scope like it would in the bootloader to continue communicating with the outside program. The UART registers look fine and seem to have all the right bits on to show UART actively enabled. Although, UARTDR neither in the bootloader or in the function call show anything in the register when going over the UART TX functions.

Some other things I have found that may be related

Imprecise bus error on SCB_FAULT_STAT register that once I turned of write caching on the ACTLR register revealed a precise bus error that had a verifies address of 0x4000000C which is WDT0 interrupt clear. this is being escalated to a hard fault and puts me in a fault ISR to loop forever.
When I add an additional while(1) to the function called to load the new program to spam UART writes it essentially causes the program to no longer perform properly up to that point despite the function call being behind a conditional that shouldn't be entered until the outside program sends its command.

I hope this is adequate information, please feel free to ask for anything thing else you feel may help solve this issue.

Thanks,

Steven

over 5 years ago

0 Marlyn Rosales Castaneda20 over 5 years ago

TI__Mastermind 25800 points

Hi Steve,

Steven Buuck said:
UARTDR neither in the bootloader or in the function call show anything in the register when going over the UART TX functions.

Do you mean that no error bits are getting set in the UARTDR register or that the DATA bits are 0?

Steven Buuck said:
Imprecise bus error on SCB_FAULT_STAT register that once I turned of write caching on the ACTLR register revealed a precise bus error that had a verifies address of 0x4000000C which is WDT0 interrupt clear. this is being escalated to a hard fault and puts me in a fault ISR to loop forever.

Is this occurring during your new main program or at what point throughout your process do you go into a fault ISR?

Best Regards,

Marlyn

0 Steven Buuck over 5 years ago in reply to Marlyn Rosales Castaneda20

Prodigy 80 points

All the bits are zero in the UARTDR, which I thought was for data. The other UART registers seem to be without errors though.

This occurs seemingly anytime a watchdog function is called. most notably in the UART write function that feeds the watchdog while UART is busy. In the bootloader I simply removed that function call from UART write and was able to get the UART function to operate without issue.

This does not solve the issue of when the loader function is called. as for 1, I do not believe it possible to remove the watchdog functionality from the loader and 2, when I removed that same watchdog functionality from the local UART write in the loader function file it did not solve the issue with the UART write not showing up on the scope.

also, as for this statement in my initial post:

Then some functions are moved to execute from RAM via memcpy and a function call to load a new main program

I failed to mention that the functions moved to RAM include:

A separate local instance of UART write in the file that the loader function is located
The loader function that is being entered where the UART is failing

0 Yashwant Temburu1 over 5 years ago in reply to Steven Buuck

TI__Expert 4145 points

Steven,

When you say some functions are copied to RAM to run. I presume you have updated the linker cmd file for those sub sections to something like this:

.func : {} LOAD = CMBANK0_SECTOR0 | CMBANK0_SECTOR1 ,
RUN = SRAM,
LOAD_START(funcLoadStart),
LOAD_SIZE(funcLoadSize),
LOAD_END(funcLoadEnd),
RUN_START(funcRunStart),
RUN_SIZE(funcRunSize),
RUN_END(funcRunEnd)

And in your main function you use memcpy(&funcRunStart, &funcLoadStart, (size_t)&funcLoadSize);

Your initial query states that you have a hard fault which is loop forever. As you have enabled watch dog, have you updated the NMI ISR to appropriately take care of watchdog overflow. If software is not able to service the NMI, then the NMIWD module will trigger a reset to the CM.

You can try running your program with watchdog disabled (SysCtl_disableWatchdog();) once to see if you are facing the same issue. I suspect it's not only the UART but whole program is stuck in the NMI ISR.

You can also refer to watchdog_ex1_nmi_handling ex in C2000Ware (C2000Ware_3_03_00_00\driverlib\f2838x\examples\cm\watchdog)

Thanks,

Yashwant

0 Steven Buuck over 5 years ago in reply to Yashwant Temburu1

Prodigy 80 points

Hi Yashwant,

I do have a similar set of instructions in the CMD file.

GROUP {

functions: LOAD = Sector_A,

RUN = C3 LOAD_START(funcsLoadStart),

LOAD_SIZE(funcsLoadSize),

RUN_START(funcsRunStart)

ALIGN(0x10)

and also use the same memcpy:

memcpy(&funcsRunStart, &funcsLoadStart, (size_t)&funcsLoadSize);

it is true that I end up in an infinite loop within an ISR for a what seems to be a watchdog error. I do not end up in the NMI ISR
but in

//*****************************************************************************
// This is the code that gets called when the processor receives a fault
// interrupt. This simply enters an infinite loop, preserving the system state
// for examination by a debugger.
//*****************************************************************************
static void
FaultISR(void){

// Enter an infinite loop.
while(1)
{
}
}

The NMI SR interrupt currently is also set up as the above ISR currently to just loop forever.

I had tried disabling the watchdog with

SysCtlPeripheralDisable(SYSCTL_PERIPH_WDOG1);
SysCtlPeripheralDisable(SYSCTL_PERIPH_WDOG0);

this still doesn't solve the UART or the problem of ending up in the fault ISR loop

0 Yashwant Temburu1 over 5 years ago in reply to Steven Buuck

TI__Expert 4145 points

Steven,

Just to narrow down the issue below are my thoughts.

When the fault occurs can you share the screenshot of the state of SCB registers.

Once the program is in fault isr, you can check the Stack pointer reg value. Goto the SP address in memory browser of ccs. Check for the latest "instruction" address in Stack .

Goto that instruction in "Disassembly view" of CCS. Here you can see which line of code caused the error. Could be an invalid memory access. Try commenting that line and rerun the program.

Regards,

Yashwant

0 Steven Buuck over 5 years ago in reply to Yashwant Temburu1

Prodigy 80 points

Hi Yashwant,

The SCB registers after entering the Fault ISR with write caching off is pictured below. Before disabling write caching it would give me an imprecise bus error or 0x00000400 in the SCB_FAULT_STAT at SCB_FAULT_ADDR of 0xE000EDF8 which I believe was a verified address