RM46L430: F021_api v02.01.01 takes data/prefetch aborts

Hi Steve,

The source is not available for distribution. I'll have a look at your scenario a bit more tomorrow and let you know if I can see any specific issues. In the meantime, if you could attach a simplified project that demonstrates the issue and post it here, I could also work on debugging the issue at my bench as well.

Good idea. I will try to build a simple test project that will be easier to debug.

Regards, Steve

I downloaded this spna183.zip about a month ago, extracted it and aimed ccsv6 at boot_can in rm46.

I changed the processor to my board's rm46l852 SOC.

I had to fuss with the include paths and resource paths to match where I put stuff in my system. Then I got it to build.

I modified the bl_dcan.c file to test just the flash problems. in updatercan right after the while(1) I put this in:

{

// hack in a loop that just does the flash part of the upgrade, not the can stuff
g_ulTransferAddress = 0x20000;
memset(g_pulDataBuffer, 0xa5, BUFFER_SIZE);
ulBytes = BUFFER_SIZE;
oReturnCheck = Fapi_BlockErase( ucBank, g_ulTransferAddress, g_ulTransferSize);

// Return an error if an access violation occurred.
//
if(oReturnCheck)
{
ucStatus = CAN_CMD_FAIL;
UART_putString(UART, "\r Erase Flash failed: ");
break;
}

/* Initialize the Flash Wrapper registers */
oReturnCheck = 0;
oReturnCheck = Fapi_BlockProgram( ucBank, g_ulTransferAddress, (uint32_t)&g_pulDataBuffer[0], ulBytes);

// Return an error if an access violation occurred.
if(oReturnCheck)
{
// Indicate that the flash programming failed.
ucStatus = CAN_CMD_FAIL;
ucUpdateStatus = 0;
UART_putString(UART, "\r Program Flash failed: ");
break;
}
else
{
// Now update the address to program.
g_ulTransferSize -= ulBytes;
g_ulTransferAddress += ulBytes;
ucUpdateStatus = 1;
}

// exit main loop
break;
}

Just running this code and waiting a few seconds of nothing, I hit pause, see it is spinning in a vector.

Interestingly, if I step into both the erase and program code, and keep stepping into the ram based code both the erase and program stuff works.

So I think you can reproduce this problem if you have a rm46 processor.

Steve

To be clear the SOC is a rm46l852 not rm46l430 if that matters.

Hi Steve,

Can you tell me where it is stuck (which line)? It might be stuck somewhere in bl_flash.c.

Regards,
QJ

Hi QJ,

No, I cannot tell where it aborts.I think it always fails in the ram based library.

I have not been able to tell from the registers. In the link reg it has 20014 which is where it was flashing starting at 0x20000

I am not sure how to decode all the abort info, so here is what I think are the interesting core and cp15 registers.

Hello Steve,

I copied your code to my project and it can erase and program the flash without any problem. 

The flash operation code should be placed and executed in SRAM rather than flash. _copyAPI2RAM_() in sys_startup.c is used to copy those code into SRAM. 

Regards,

QJ

Hi QJ,

Thanks, I hope it will work.

Like I said it will work for me if I just single step through the code. And yes ccsv6 will single step up into the RAM where the library is available for disassembly. So maybe a problem in some kind of speed setup?

Did you test on a rm46x processor?  My crystal is 16Mhz so I assume the library setup the other clocks as it likes (I think it was 160Mhz). Also I assume the library handles flash wait state setups.

Did you start with the code in spna183.zip ?

I am not sure where I got the f021_api, I think it was pre-built in some monster halcogen zip file.

Steve.

Hi QJ,

I am confused about the visible parts  of the library and the RM46x 16 32 Bit TRM spnu514b.pdf -

Your library uses:

C:\Users\scalfee\scalfee_1\scalfee_1\Triton\main\Ctl\SafetyMCU_Bootloader\inc\F021_API\Constants.h:
49 #define F021_FLASHECC_MAP_END 0xF04FFFFFU
50
51: #define F021_CPU0_REGISTER_ADDRESS 0xFFF87000U
52
53 /* Specific TI OTP Offsets */

C:\Users\scalfee\scalfee_1\scalfee_1\Triton\main\Ctl\SafetyMCU_Bootloader\inc\F021_API\Registers.h:
74 #define FWP_WRITE_OFFSET 0x120U
75 /* Macro that creates a byte accessor pointer to the FWPWRITEx registers */
76: #define FWPWRITE_BYTE_ACCESSOR_ADDRESS ((FwpWriteByteAccessorType*)(F021_CPU0_REGISTER_ADDRESS + 0x120U))
77 /* Macro that creates a byte accessor pointer to the FWPWRITE_ECC register */
78: #define FWPWRITE_ECC_BYTE_ACCESSOR_ADDRESS ((FwpWriteByteAccessorType*)(F021_CPU0_REGISTER_ADDRESS + 0x140U))
79 /* Macro that creates a dword accessor pointer to the FWPWRITEx registers */
80: #define FWPWRITE_DWORD_ACCESSOR_ADDRESS ((FwpWriteDWordAccessorType*)(F021_CPU0_REGISTER_ADDRESS + 0x120U))

But the trm does not talk about registers at offset 0x120 from the flash base a fff8_7000

In fact it skips them altogether. From page 279

FFF8 706Ch FDIAGCTRL Diagnostic Control Register Section 5.8.26
FFF8 7070h FRAW_DATAH Uncorrected Raw Data High Register Section 5.8.27
FFF8 7074h FRAW_DATAL Uncorrected Raw Data Low Register Section 5.8.28
FFF8 7078h FRAW_ECC Uncorrected Raw ECC Register Section 5.8.29
FFF8 707Ch FPAR_OVR Parity Override Register Section 5.8.30
FFF8 70C0h FEDACSDIS2 Flash Error Detection and Correction Sector Disable Register 2 Section 5.8.31
FFF8 7288h FSM_WR_ENA FSM Register Write Enable Section 5.8.32
FFF8 72A4h FSM_SECTOR FSM Sector Register Section 5.8.33

Maybe you can shed some light on the actual situation on my SOC?

Thanks, Steve

Hi,

I just confirmed that I am using the latest f021 API v02.01.01

Steve

HI QJ

I am still trying to get this to build. I finally figured out how to load the exact compiler version the project required.

Now I cannot find the required RTS library used in your project "rtsv7R4_A_le_eabi.lib". This exists in the older compiler but not in 16.6? So the linking fails.

I am using  ccs Version: 6.2.0.00050

Regards, Steve

Hi QJ,

Using your project I was able to get my small hack test to work.

I used the same flash api as before, but the SafetyMCU_Bootloader code you used is different from the one I downloaded. So the difference must be there.

Thanks, Steve

Hi Steve,

Attached please find the CAN bootloader with your code in the while(1) loop. It works well for step over and one time execution. The bootloader uses flash API rev 2.01.01, and the library is located at C:\ti\Hercules\F021 Flash API\02.01.01

Regards,

QJ

6175.SafetyMCU_Bootloader.zip

Hi QJ,

Is this zip different from the one you send earlier? I was also able to get the test code to run.

Thanks, Steve

Hi Steve,

The only difference is that the new zip project uses the header files and Flash API in installation folder (c:\ti\hercules\...) rather than the files and lib in bootloader folder. And the new zip doesn't include other bootloaders (SPI, UART, etc).

Regards,

QJ

Hi QJ,

I have things working pretty good now.

I did notice a bad instruction trap on rm46.

If I call Fapi_BlockErase(0, pagealignedaddr, 1) I get a bad inst trap.

If I call it with Fapi_BlockErase(0, pagealignedaddr, 0x400) it works.

Neither 1 or 0x400 is the page size, so it is somewhat surprising. However I give the workaround. Consider this a bug report.

Regards, Steve

Writing zeros.

Is there a minimum write size to this flash? On the TIVA I could erase a page and then clear it bit by bit with a write for every bit. This allows me to create a record of system activity and then mark its sequential occurrence in flash. So any crash or power cycle could continue where I previously left off.

On the Hercules there seems to be a minimum write size - if I write one bit to zero in a byte and the byte is not all ones, it does not seem to cause an error, but on a power cycle the contents are lost. Is there a minimum write size? Is it one byte? Is it 16 bytes, Is it a full page?

Thanks for the advice.

Steve

Steve,

The flash on the RM46 is ECC protected, and sometimes when you try to do something seemingly 'ok' like flip a bit from '1'->'0' this
would result in one or more of the ECC bits being changed from 0 -> 1 which requires a sector erase. So it really doesn't lend itself
to this use case.

You should look at the FEE driver if you need EEPROM type functionality. This emulates EEPROM with the special EEPROM emulation bank.

Hi Anthony,

Do you know what the alignment requirements and minimum write size actually are for the flash? I think I have enough flash and would like to keep it simple.

Thanks, Steve

Steve,

From a standpoint of ECC it's 64-bits (and aligned to 64-bit boundaries).

Steve,

You should also take note of the maximum W/E cycle capability of program flash vs. the data flash designated for EEPROM emulation. There is a very substantial difference in the max write/erase capability between the two inherent to the bank design. Also, using the FEE driver, the ECC updates and data write sizes are managed by the FEE drivers so no need to dive deep into flash emulation principles. This was handled in HW/ROM by the TIVA devices which is why it seemed transparent to you. Hercules has maintained a higher level of flexibility which means there is less built in functionality in HW and a bit higher complexity in understanding the algorithms.

Hi Chuck,

Do you or Anthony know what file contains the latest and known good "Fee driver" googling on the site is not clear.

Steve

Steve,

It's included with HALCoGen.