TMS320F28384S: Copy Connectivity Manager (CM) RTS library functions to RAM

Hello Omer,
this example is very simple and didn't help me.

Anyway I found the RTS library object modules I was looking for, analyzing better the .map file.

Sfortunately, I haven't resolved my problem yet.
During erase/write operations I get an Hard Fualt exception, probably because some other function invoked by the running system tick, is still in flash.

How can I investigate this problem?
How can I get the reason of the hard fault?

Thank you,
Carlo

Carlo Taboni33 said:

this example is very simple and didn't help me.

I apologize if I didn't understand your question correctly, I thought you were looking for an example of how to load a function to Flash and then run it from RAM.

Carlo Taboni33 said:

During erase/write operations I get an Hard Fualt exception, probably because some other function invoked by the running system tick, is still in flash.

How can I investigate this problem?
How can I get the reason of the hard fault?

Is it possible for you to step through your code to determine where/what exact instruction the hard fault occurs on? Can you show a screenshot of the message and the Disassembly for what code the program is running for this fault?

If the issue is what you're saying and a function that is being erased is being called from elsewhere, then the solution is simply to move that function out of that particular Flash bank you're erasing.

Hello Omer,
the problem occours when the system tick, that runs in RAM, executes the following macro, during a flash erase/write operation.

As you can see all the __aeabi_xxx() double-precision functions run from RAM.

So, may be that I have a crash during flash erase/write operations, because there are some other nested functions, called from the __aeabi_xxx() ones, that still run in flash?

I tried to find an alternative solution, by adding the F suffix to the floating-point constants used by the macro, to cast them to single-precision values.

In this case the macro disassemby changes in this way and the __aeabi_xxx() double precision functions don't exist any more:

In this case, anyway, I have another kind of problem.
Now the Hard fault is generated as soon as the macro is executed, and not only during flash erase/write operations.
in particular, the crash occours when executing the vmov instruction.

What a mess...

Thank you,
Carlo

Carlo Taboni33 said:

So, may be that I have a crash during flash erase/write operations, because there are some other nested functions, called from the __aeabi_xxx() ones, that still run in flash?

That's correct, if there are any functions that are called into the Flash bank which is being programmed/erased then you will have an issue. You can always look in the Memory Browser and Disassembly view (entering the appropriate memory locations) to view the content of the Flash bank.

Carlo Taboni33 said:

I tried to find an alternative solution, by adding the F suffix to the floating-point constants used by the macro, to cast them to single-precision values.

In this case the macro disassemby changes in this way and the __aeabi_xxx() double precision functions don't exist any more

What FPU configuration do you have set in your Project Properties? While I believe you can still use single-precision when double-precision is enabled, all the added libraries must be compiled with the same FPU configuration.

Omer Amir said:

What FPU configuration do you have set in your Project Properties? While I believe you can still use single-precision when double-precision is enabled, all the added libraries must be compiled with the same FPU configuration.

I use the following configuration:

I'm not too familiar with this FPU option since it seems unique to the CM. If you've verified that no functions are being called from the Flash bank as it's being programmed/erased, let me know, since this may need to go to another expert.

Hello Omer,

I don't have a method other from analyzing the .map file, to be sure that I have copied all functions to RAM.
The only think I am sure is that if I disable interrupts during flash/erase operations I dont't have a Hard Faults.
The only enabled interrupt is the system tick.
So I guess that there is something in the tick calling stack that accesses the flash bank.
Anayzing the disassembly, I can't find functions that are still in flash.

I don't really know how to get out from this trouble...

Thank you,
Carlo

Carlo Taboni33 said:

I don't have a method other from analyzing the .map file, to be sure that I have copied all functions to RAM.

You're getting the fault by debugging, correct? You can open the Disassembly view by going to View > Disassembly (you already showed me screenshots of it from before). If you're not sure about the address of a function, you can enter it into the Expressions window. Can you also show me the actual message you see when you get a hard fault? I'm not sure it was shown in the screenshots you attached previously.

Hello Omer,
I don't know what you intend with actual message.

This is the state of the processor when the hard fault happens:

Carlo Taboni33 said:

This is the state of the processor when the hard fault happens

Thanks, the screenshot with what ISR is being hit is helpful. Can you take a look at the return program counter (RPC)? This should show where the program was originally executing, which may show which function/instruction was being used which caused the fault.

Carlo Taboni33 said:

The only think I am sure is that if I disable interrupts during flash/erase operations I dont't have a Hard Faults.
The only enabled interrupt is the system tick.
So I guess that there is something in the tick calling stack that accesses the flash bank

Based on this, I would agree that something with system tick (either that function or any function/code it's using) is being used in the Flash bank being programmed/erased. If the program works fine without interrupts, then one of the interrupts likely has code that's being used from that Flash bank.

Hello Omer,
I cannot find a RPC register, but the return address should be indicated by the Link Register (LR).

The pattern 0xFFFFFFF indicates that it is a return from an exception handler, while the last 1 indicates that it is a return in handler mode (and not thread mode). So it seems as if the faultISR() is invocated from another exception (the SysTick?).

Moreover, analyzing the call stack when the faultISR() is invoked, the PC was loaded with 0xFFFFFFF0, that suggest again that the faultISR() is invoked from another exception.

Finally, analyzing the CFSR (Configurable Fault Status Register), I see that:
- bits PRECISERR and BFARVALID a set, indicating that the erroneous address in stored in BFAR (BusFault Address Register)
- bit STKERR is set, indicating that the derived bus fault has occurred on exception entry.

The address stored in the BFAR register is 0x1FFFBFF8, that is 8 bytes lower than the stack base address.

May be that something has gone wrong while unstanking the SysTick exception?
I don't know, my knowledge of the Cortex architectures is still pretty limitated.

Thank you,
Carlo

Hi Carlo,

Thanks for your follow-up, but this looks like you have found the location of the issue correct? The addresses where the issue is being mentioned is the location of the fault.

For causes, it looks like maybe something is possibly trying to access a range wider (or smaller) than the bus can handle.

Regards,

Vince

Hello Vince,
yes it seems something like that.

The reason of the erroneous behaviour remains unknown, anyway it seems that I can workaround the problem by disabling interrupts during erase/write operations.

So this issue can be considered closed, even if not resolved.

Thank you Omer and Vince for support.

Regards,
Carlo