Trouble porting Concerto M3 f021 flash example to my project

Here are the two zip files of my link command file and map file

2642.M3Map.zip4338.m3_link.zip

Larry,

(1) Which version of Flash API are you using? V1.50.0 or V1.51.0?  You should use V1.50.0. 

(2) Could you try disabling ECC in code before you start using API functions?  You have to write a value of 0x0 in the 32-bit ECC_Enable register mapped at 0x400FA600 to disable ECC on M3.  Let me know if it works after disabling ECC. 

Thanks and regards,

Vamsi

Hi Vamsi,

Thanks for the quick answer.  I'm of course using the V1.51.0.  Do I need to be running the 1.50 before doing the disable of the ECC?

Thanks again,

Larry

Larry,

C2000 users should use V1.50.

Please disable ECC before calling API functions.

Thanks and regards,

Vamsi

Hi Vamsi,

I updated to V1.50, and now link against that F021_API_CortexM3_LE.lib.  With

HWREG(FLASH_ERROR_BASE + FLASHERR_O_ECC_ENABLE) = 0x0;

before calling APIs, I was able to step over Fapi_setActiveFlashBank() and get to the end of the subroutine.

What does that indicate?  And will I need to zero the ECC like that when I erase, and when I write the flash?

Thanks very much,

Larry

Larry,

Good that you are able to execute the routine now.

Which device are you using?  F28M35x or F28M36x? 

After you shifted to V1.50, did you try executing the routine with out disabling ECC?  If not, could you try executing the routine using V1.50 API and with out disabling ECC?  Let us know how it goes.  This might help us understand the issue.

You dont have to disable ECC when erasing/programming Flash.  However, if you are not programming ECC along with Flash data, then you have to disable ECC before you read or fetch from Flash to avoid ECC errors. 

Thanks and regards,

Vamsi

Hi Vamsi,

Thanks again for your help, it's so nice to feel that I'm making progress! 

I'm using the F28m35x.  I did try the routine without the disable of ECC, and I am able to step successfully over setActiveFlashBank(), but when I keep stepping and call my eraseFlash() and when I get to

Fapi_issueAsyncCommandWithAddress( Fapi_EraseSector, (uint32 *) sectorStart );, I get the same

Cortex_M3_0: Can't Run Target CPU: (Error -1268 @ 0x90001) Device is locked up in Hard Fault or in NMI. Reset the device, and retry the operation. If error persists, confirm configuration, power-cycle the board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 5.0.762.0)

Another data point is that with the ECC disabled, I get the same result at the same Fapi_issueAsyncCommandWithAddress( Fapi_EraseSector..)

What is the difference between 1.50 and 1.51? 

The only change I made to go to use the 1.50 was to use the 1.50 library for linking, I didn't change any code.  Is that a problem?

Thanks,

Larry

Larry,

Thank you for confirming that you are seeing this issue with both V1.50 and V1.51 if you do not disable ECC.

C2000 users are supposed to use V1.50 but not V1.51. 

V1.51 is for Hercules devices and MSP430 devices.  V1.51 should not have C2000 related API libraries.  TI will work to remove them.

If you are using Fapi_UserDefinedFunctions.c, use the one provided with V1.50.  Also, if you are using any headers from V1.51, replace them with the headers from V1.50.

I did not understand your statement "Another data point is that with the ECC disabled, I get the same result at the same Fapi_issueAsyncCommandWithAddress( Fapi_EraseSector..)" clearly.  Do you mean to say that you are getting the error message even when you disable ECC? 

Thanks and regards,
Vamsi    

Hi Vamsi,

What I meant to write is that irrespective of the ECC state, I was able (with 1.50 library)  to step through my initializeFlash() but  when I next called my eraseFlash() and in there I tried to step over Fapi_issueAsyncCommandWithAddress( Fapi_EraseSector..) I got the same error message

Thanks,

Larry

Hi Vamsi,

I wondered if you had any hints or suggestions about what to try next  to progress with this erase flash.

Thanks,

Larry

Larry,

Could you put a breakpoint in BUS FAULT ISR and check Flash ECC registers to see if there is any ECC error?

Are you executing the Flash API functions from RAM or Flash?  Flash API functions have to be executed from RAM.

What is the SYSCLOCK frequency at which M3 is running?  Did you set the wait states appropriately? 

What parameters did you pass for the Fapi_issueAsyncCommandWithAddress() function?

Thanks and regards,
Vamsi

Larry,

along with what Vamsi asked for, can you provide below details to pin the problem?

1.> Do you have a HARD FAULT ISR installed?, if not please install one and put a break point. Once you hit it can you take provide the details of the registers given in Table 26-19, page 1688, section 26.8.1 Fault Type of chapter 26 - Cortex-M3 processor, in device TRM?

2.> make sure you have all the interrupts disabled before you erase any flash, otherwise there might be a lingering interrupt thats gets triggered intermittently. You cannot disable NMI, so make sure you have an NMI ISR installed also and put a break point over there too.

3.> if you need to have interrupts running, then make sure all the handlers are in RAM and all the data/stack has no contention with flash API in question.

4.> do you have passwords programmed or erased?

Does this happen while erasing any partiular sector or number of sectors and is it reproducable everytime?

Best Regards

Santosh

Hi Vamsi, Santosh

Thanks for the quick replies!  I am almost running out of  time for for tonight, but I'll address the remaining questions tomorrow morning. 

I think I am running from RAM, I do memcpy(&RamfuncsRunStart, &RamfuncsLoadStart, (size_t)&RamfuncsLoadSize); in my main just before calling flashInit() to set up wait states.  Tomorrow I'll open a dissasembly window and verify.  I'm running M3 at 75 MHz, and I see the correct #ifdefs selected when I walk through the API code that's confirming.   I run through this codeand definitely get the 75MHz branch

    // Before performing FSM operations, set the waitstates for FSM
    // operations calculated using RWAIT = (SYSCLK/(2*24MHz))-1
    // If RWAIT results in a fractional value, round it up to the nearest
    // integer.
    // Please note that RWAIT for read operation should be calculated
    // differently.  See Internal memory guide section in TRM
    #if CPU_FRQ_100MHZ
    HWREG(FLASH_CONFIG_BASE + FLASHCTRL_O_FRDCNTL) = (2 << FLASHCTRL_FRDCNTL_RWAIT_S);
    #endif

    #if CPU_FRQ_75MHZ
   HWREG(FLASH_CONFIG_BASE + FLASHCTRL_O_FRDCNTL) = (1 << FLASHCTRL_FRDCNTL_RWAIT_S);    #endif

this is my call to the issue Async, sectorStart is uint32 *

oReturnCheck = Fapi_issueAsyncCommandWithAddress( Fapi_EraseSector, sectorStart );

Now I've got to boogy, I'll send some more tomorrow morning!

Thanks very much again,

Larry

Hi Vamsi,  Santosh,

I did double check, and I am running from flash :(  So thanks for the suggestion to check!  Today I'm addressing another matter,  I will be out of town next week, so I won't be available to work with you, but I'll be back the following week, to try it running from RAM. 

Thank you very much for the help

Larry

Hi Vamsi, Santosh,

I'm back in town, looking at this issue!  I have added  #pragma CODE_SECTION( initializeFlash,"ramfuncs"); s.t. my routine will be running in RAM, and sure enough, the disassembly shows me at the address in RAM, the first instruction at 0x200018d4:  0xFFFFFFFF VCVT.U32.F32 Q15, Q15, #1 ( does that seem normal?) The code following that line looks like it's doing the FlashGainPump().

As per your suggestions, I put in a HFAULT and BUS error handlers, and break points.  Now when I step over the instruction at 200018d4, I hit the break point in HFAULT handler.  We don't hit the BUS error fault handler, ?because we hit the HFAULT first?  The debugger reports Trouble reading Memory Block at 0x20001952 on Page 0, so that seems like a symptom

The hw_nvic.h file defines the NVIC_HFAULT_STAT at E000ED2C, and what I make of the manual in section 27.6.12 seems to be that the NVIC_FAULT_STAT  at 0xE000ED28 includes the registers we want, offsets D28, D29, D2A

0xE000ED28:            00 01 00 00    40 00 00 00    00 00 00 00    E0 00 ED F8    E0 00 ED F8

I hope this is the register information that you wanted?

Thanks for any information you can provide to me.

Larry

Hi Vamsi, Santosh,

To recap, I put in NMI, HARD, and BUS fault interrupt handlers.  Right when I step over the first instruction, I get a Hard Fault interrupt.

So if I grabbed the right information from the right place, that looks like  I don't have a memory management fault or a bus fault, but hit an unaligned access?  Is that right?

I notice that the interrupt vectors g_pfnRAMVectors are going in at 0x20002000, maybe the registers I want are there?

I'm pretty baffled, so any guidance you can provide would be great!

Thanks,

Larry

Larry,

I guess all the faults are disabled by default so any fault will end up going into hard fault. So you will have to look into internal regs to decode which one is it.

One thing to root cause is why yoour code is trying to execute something from memory when it is 0xFFFFFFFF? obviously some code is not being copied or loaded properly at the RUN address. Inspect your linker command and memory map files for the function.

Best Regards

Santosh

Hi Santosh,

Thanks for the help!   Did I read the correct register content when I read the E000ED28 memory address?  Or should I be reading some other memory address?

My map file has addresses for the "trampoline" that aren't 32bit aligned (pasted below), what causes that, do I maybe not have enough memory?

FAR CALL TRAMPOLINES
callee name               trampoline name
   callee addr  tramp addr   call addr  call info
--------------  -----------  ---------  ----------------
$.text:Fapi_doVerifyByByte:F021_API_CortexM3_LE.lib<Verify.obj>$0x0  $Tramp$TT$L$PI$$$.text:Fapi_doVerifyByByte:F021_API_CortexM3_LE.lib<Verify.obj>$0x0
   20001721     0021cd3c     0021847c   flashapi.obj (.text:writePacketToFlash)
Example_Error             $Tramp$TT$L$PI$$Example_Error
   200019ad     0021cd48     0021846c   flashapi.obj (.text:writePacketToFlash)
$.text:Fapi_getFsmStatus:../F021_API_CortexM3_LE.lib<FlashStateMachine.obj>$0x0  $Tramp$TT$L$PI$$$.text:Fapi_getFsmStatus:../F021_API_CortexM3_LE.lib<FlashStateMachine.obj>$0x0
   20001765     0021cd54     0021845c   flashapi.obj (.text:writePacketToFlash)
$.text:Fapi_checkFsmForReady:../F021_API_CortexM3_LE.lib<FlashStateMachine.obj>$0x0  $Tramp$TT$L$PI$$$.text:Fapi_checkFsmForReady:../F021_API_CortexM3_LE.lib<FlashStateMachine.obj>$0x0
   200016f5     0021cd60     00218444   flashapi.obj (.text:writePacketToFlash)
$.text:Fapi_issueProgrammingCommand:F021_API_CortexM3_LE.lib<Program.obj>$0x0  $Tramp$TT$L$PI$$$.text:Fapi_issueProgrammingCommand:F021_API_CortexM3_LE.lib<Program.obj>$0x0
   20000edd     0021cd6c     0021843c   flashapi.obj (.text:writePacketToFlash)
FlashInit                 $Tramp$TT$L$PI$$FlashInit
   20001849     0021cd78     00217aea   Main.obj (.text:M3MainLoop)
eraseFlash                $Tramp$TT$L$PI$$eraseFlash
   2000177d     0021cd84     0020f2ec   serialDownload.obj (.text:ymodemReceive)
                             0020f50c   serialDownload.obj (.text:ymodemReceive)
initializeFlash           $Tramp$TT$L$PI$$initializeFlash
   200018d5     0021cd90     0020f2e6   serialDownload.obj (.text:ymodemReceive)
                             0020f504   serialDownload.obj (.text:ymodemReceive)
Fapi_serviceWatchdogTimer  $Tramp$TT$L$PI$$Fapi_serviceWatchdogTimer
   0021cd39     200013a4     2000133e   F021_API_CortexM3_LE.lib : Read.obj (.text:_Fapi_loopRegionForValue)
                             2000138c                            : Read.obj (.text:_Fapi_loopRegionForValue)
                             20001512                            : Read.obj (.text:_Fapi_loopRegionForValueByByte)
                             2000175a                            : Utilities.obj (.text:_Fapi_scaleCycleValues)
Fapi_setupBankSectorEnable  $Tramp$TT$L$PI$$Fapi_setupBankSectorEnable
   0021c4f9     20001570     20001550   F021_API_CortexM3_LE.lib : FlashStateMachine.obj (.text:_Fapi_setupSectorsForWrite)
Fapi_setupEepromSectorEnable  $Tramp$TT$L$PI$$Fapi_setupEepromSectorEnable
   0021c371     2000157c     20001556   F021_API_CortexM3_LE.lib : FlashStateMachine.obj (.text:_Fapi_setupSectorsForWrite)
FlashGainPump             $Tramp$TT$L$PI$$FlashGainPump
   0021c679     20001958     200018e2   flashapi.obj (ramfuncs:initializeFlash)

[12 trampolines]
[17 trampoline calls]

Larry,

earlier you mentioned that 'initializeFlash' function at RAM address has 0xFFFFFFFF, can you verify if there is proper code in the flash where 'initializeFlash' is loaded? if yes then as you expect that code is not getting copied to RAM during RAMfuncs copy routine. Verify if you are calling the memcpy routine in your main that copies the RAMFUNCS from flash to RAM. One of the controlSuite Flash examples should show this.

Best Regards

Santosh

Santosh,

The address is not FFFFFFFF, what I wrote was from the disassembler view, " first instruction in initializeFlash() at address 0x200018d4:  0xFFFFFFFF VCVT.U32.F32 Q15, Q15, #1"  so I wondered if that was a valid instruction code.   I definitely am calling the  the memcpy right after starting my main.  Is it a problem that main() is running in FLASH? 

void main(void)
{
   volatile unsigned long ulLoop;

   // Disable protection so that we can write registers
   HWREG(SYSCTL_MWRALLOW) = 0xA5A5A5A5;

   // Set up main clock tree for 75MHz - M3 and 150MHz - C28x
   SysCtlClockConfigSet( SYSCTL_SYSDIV_1 | SYSCTL_M3SSDIV_2 | SYSCTL_USE_PLL | (SYSCTL_SPLLIMULT_M & 0x0F) );

   // Disable clock supply for the watchdog modules
   SysCtlPeripheralDisable(SYSCTL_PERIPH_WDOG1);
   SysCtlPeripheralDisable(SYSCTL_PERIPH_WDOG0);

   // Enable processor interrupts.
   IntMasterEnable();

   // Copy time critical code and Flash setup code to RAM
   // This includes hopefully ??? the flash api
   //  and InitFlash();
   // The  RamfuncsLoadStart, RamfuncsLoadSize, and RamfuncsRunStart
   // symbols are created by the linker. Refer to the device .cmd file.
   memcpy(&RamfuncsRunStart, &RamfuncsLoadStart, (size_t)&RamfuncsLoadSize);

Larry,

I meant the value at the RAM address shouldn't be 0xFFFFFFFF, thats not a valid instruction if your code is branching to that address. Since you can clearly say that this is the first instruction in initializeFlash() location...can you inspect the memory where this function is loaded in flash? is that instruction value correct in flash (not 0xFFFFFFFF)? then after you run through the copy routine in main, inspect the value in RAM address... is it copied properly?

Larry Ansell said:

The address is not FFFFFFFF, what I wrote was from the disassembler view, " first instruction in initializeFlash() at address 0x200018d4:  0xFFFFFFFF VCVT.U32.F32 Q15, Q15, #1"  so I wondered if that was a valid instruction code.   I definitely am calling the  the memcpy right after starting my main.  Is it a problem that main() is running in FLASH? 

Best Regards

Santosh

Hi Santosh,

I'm glad to report that not only were the instructions correct in flash, but they were copied out correctly to RAM.  I was declaring a 1024 byte buffer on the stack, and that was causing all the problems.  Now I can walk through the intializeFlash with no problems!  Now I call the erase code, the first time through for sector M, it verified, but when it was doing the erase of "L" it threw a hard reset during verification.  I have a suspicion that my calling code (running from flash) was running in that sector.  So I tried to run from RAM, but soon discovered a function ParseRCI() whose code was all zeroes in RAM, but was valid looking in flash.  This function clearly has the #pragma ramfunc

#pragma CODE_SECTION( chrrdy, "ramfuncs");
#pragma CODE_SECTION( ProcessChar, "ramfuncs");
#pragma CODE_SECTION( ParseRCI, "ramfuncs");

Both the chrrdy() and ProcessChar() are in the FAR CALL TRAMPOLINES section of the map file, but ParseRCI() isn't.  What would you guess I'm doing wrong to get that effect, please?

Thanks,

Larry

Larry,

glad to know that you found one issue. more often there could be others, I would start by trying to find out where the ParseRCI addresses in RAM memory are zeroed out. Put a break point at the end of the memcpy function that copies ParseRCI to RAM and see if that contents are valid, then again inspect the memory when you branch to the function in RAM is it zeroes? so that means some code is zeroing it out and thats your culprit.

Best Regards

Santosh

Hi Santosh,

Happy Friday!  I didn't explain clearly - right after the memcpy, it's already all zeros in RAM, but good in flash.  This code is single threaded, so I think the routine is not getting into ramfuncs!  As I mentioned previously, I have 3 routines all together with #pragma at the top of the file, like so

#pragma CODE_SECTION( chrrdy, "ramfuncs");
#pragma CODE_SECTION( ProcessChar, "ramfuncs");
#pragma CODE_SECTION( ParseRCI, "ramfuncs");

Two of the routines, the chrrdy() and ProcessChar() show up in the FAR CALL TRAMPOLINES section of the .map file, but ParseRCI() doesn't.   Do you have another guess as to what's happening?

Thanks very much for your help,

Larry

Larry,

check for spelling mistakes in the PRAGMA and linker command and function names, also take ParseRCI out of ramfuncs and see if the length of ramfuncs changes or not, that might tell you what is going on. Try moving ParseRCI to another section of memory...or maybe it is too big to fit in RAM?

I'll think about any other things that can help debug ...

Best Regards

Santosh

* removed text - opened a new ticket.