Hercules RM48L952ZWT Flash Erase Does not Work Using FAPI API

Tammy,

In CCS, expand your project to display the source code.
Right click on system.c and select Show Build Setting.
From there, select CCS Build-> ARM Options->Optimization and set Optimization level to off and Speed versus size to none.

As I said, this will only affect system.c all other files will be compiled with the properties set at the project level.

Tammy,

Here is the zipped folder: 7103.SafetyMCU_Bootloader_Original_FlashIssue.zip

In SafetyMCU_Bootloader_Original_FlashIssue\SafetyMCU_Bootloader_Original\RM48\boot_uart I've renamed the CCS project to:

"boot_uart_RM48_Tammy"

That way you can import it in the same workspace as your actual project.

I did another modification that should be irrelevant for the problem you are seeing in system.c
In void setupPLL(void) I've added the following code:

    /* Disable PLL1 and PLL2 */
    systemREG1->CSDISSET = 0x00000002U | 0x00000040U;
    /*SAFETYMCUSW 28 D MR:NA <APPROVED> "Hardware status bit read check" */
    while((systemREG1->CSDIS & 0x42U) != 0x42U)
    {
    /* Wait */
    }

    /* Clear Global Status Register */
    systemREG1->GBLSTAT = 0x301U;

This is the way the latest Halcogen code is generated. The rational is, before changing the PLL setup, it is recommended to disable the PLL first.
That was not done in the Halcogen release used when the bootloader was developed.

As summary, in bl_main.c on line 76 I've changed:

uint32_t g_ulUpdateStatusAddr = 0x0FFC0;             //was 0x07FC0

The compilation optimization for system.c are off.

Hi Jean-Marc. Thank you. I downloaded and imported this project and still have that same problem as above. In the memory browser it erases flash, but it does not exit the Fapi_issueAsyncCommandWithAddress() function and loops in that exception code in sys_intvecs.asm (and I gave it about 30 seconds of waiting).   How long should it take? Did you select option #3 on the test menu or tried erasing the Flash with a different menu option and Fapi function?

Tammy,

You can only set breakpoint in the Flash code after you reach main. Remember the code is in Ram only after it has been copied to Ram. I will have a look tomorrow.

Tammy,

Sorry for the misunderstanding, but I was using the option 1 and not 3.

So when using 3, I realize that the binary filename is hard-coded. So I've copied a binary file on the SD Card with following name:

newb.bin

The code was failing opening this file and I had to change the following line:

from: char newFileName[9] = "/newb.bin";
to       char newFileName[9] = "newb.bin";

Than I was able to see the problem you are experiencing.
In sd_card.c, there are 2 function that have to be executed from RAM:

bootloader_FlashApplicationRegion and bootloader_FlashEraseSector

It is not possible to copy the full sd_card.obj in RAM (not enough space) so here is the trick.
Via the linker command file, you can specify where a section is mapped as following:

   flashAPI :
   {
     ..\Debug\Fapi_UserDefinedFunctions.obj (.text)
     ..\Debug\bl_flash.obj (.text)
 This will map all the code section (.text) from UserDefinedFunctions.c and bl_flash.c in the section flash_API.

In order to map only a specific function to a section, it is necessary to assign the function to a section name.
In the compiler option-> Advance Options there is a switch (On/Off) name: "Place each function in a separate subsection" The default is Off.
So for the file sd_card.c change it to On.

Now, in a similar way the following syntax can be used in the linker command file:

     ..\Debug\Biolase\source\sd_card.obj (.text:bootloader_FlashApplicationRegion)
     ..\Debug\Biolase\source\sd_card.obj (.text:bootloader_FlashEraseSector)

This will force the linker to link these 2 functions part of sd_card.obj in the flashAPI so at run time this section can be copied in RAM.

In your implementation, you are using more Flash_API than the original bootloader was. I've found Fapi_doBlankCheck.
This is the same, this function has to be in the flashAPI section to be executed from RAM.

In the linker command file, the following line has to be added:

                                     Read.Fapi_doBlankCheck.obj

If other Flash API are used, they will have to be listed as well in the linker command file.
To make room in RAM to fit all these new routine, I had to remove the following code:

//     ..\Debug\bl_flash.obj (.text)

That means the option 1 (Download via UART) does not work anymore.

After all these modification, I was able to execute your code further, but is is falling after the Fapi_doBlankCheck. It is certainly an argument problem, size or other. I think you have all element in hands to continue the debug on your own.

Please let me know if these explanation were useful.

Here is the full flashAPI definition in the linker command file:

   flashAPI :
   {
     ..\Debug\Fapi_UserDefinedFunctions.obj (.text)
//     ..\Debug\bl_flash.obj (.text)
     ..\Debug\bl_sdcard.obj (.text)
     ..\Debug\Biolase\source\sd_card.obj (.text:bootloader_FlashApplicationRegion)
     ..\Debug\Biolase\source\sd_card.obj (.text:bootloader_FlashEraseSector)
     --library= F021_API_CortexR4_LE.lib < FlashStateMachine.IssueFsmCommand.obj
                                           FlashStateMachine.SetActiveBank.obj
                                           FlashStateMachine.InitializeFlashBanks.obj
                                           FlashStateMachine.EnableMainSectors.obj
                                           FlashStateMachine.IssueFsmCommand.obj
                                           FlashStateMachine.ScaleFclk.obj
                                          Init.obj
                                          Utilities.CalculateEcc.obj
                                          Utilities.WaitDelay.obj
                                          Utilities.CalculateFletcher.obj
                                          Read.Fapi_doBlankCheck.obj
                                          Read.MarginByByte.obj
                                          Read.Common.obj
                                          Read.FlushPipeline.obj
                                           Read.WdService.obj
                                          Async.WithAddress.obj
                                          Program.obj > (.text)
   } load = FLASH_API, run = SRAM, LOAD_START(api_load), RUN_START(api_run), SIZE(api_size)
In BOLD are the modification I've made.

Tammy,

Did you modified the compile option for the auto section name?

Also check that this function is in sd_card.c

If not do the same for the file that contains this function.

Tammy,

I did check on my setup about the bootloader_FlashEraseSector warning during link time.

In my case, to be able to debug the code easier, I've removed all optimization. In this configuration the linker does not complain about the section.

Apparently when the code is optimized, this routine seems to be embedded and does not show up in the map file. I did check at run time and this code is executed.

So to summarize, if I don't use optimization on the project, the linker does not complain about this section.
With optimization, these is a warning at link time on the specific section, but the code executes correctly.

Hi Jean-Marc. Thank you. Yes I removed all the optimizations on the other files as well, and the warning is gone. After the erase flash is complete, and we are ready to program the flash .bin file on the sdcard (using the simple file system io API that you say I integrated).  With the limitations of our size of RAM you mentioned. What is the best way than to program the binary file into flash? can we just use standard fio functions and just limit the size of the buffer?

i.e., psuedocode

...

bank_number = 0;

FlashDestination = 0x00020000

fname = &newFileName[0];

iFResult = f_open(&fname, buf, FA_READ);

while (not end of file)

{

//

// Enter a loop to repeatedly read data from the file and display it, until

// the end of the file is reached.

//

do

{

    //

    // Read a block of data from the file. Read as much as can fit in the

   // temporary buffer

    //

    iFResult = f_read(&fname, buf, sizeof(buf)  (UINT *)&ui32BytesRead);

   //

   // track size of the last chunk of the file that was received.

   //

   g_Size = g_Size + sizeof(buf);

   //

   // If there was an error reading

   //

   if(iFResult != FR_OK)

  {

   UARTprintf("Problem reading file \r\n");

   g_Size = 0;

  break;

  }

    oReturnCheck = Fapi_BlockProgram( bank_number, FlashDestination, (unsigned long)buf, buf_size);

    FlashDestination = FlashDestination + buf_size;

    if (Flash_Destination >= 0x00180000)

    {

       bank_number = 1;

    }

}

while(ui32BytesRead == sizeof(buf) - 1);

....

Thank You Again.

Tammy,

This is the way to go.
Yes you can read the binary file to a buffer and program it to flash. This is the way it is done with the UART version.
We receive block of data (check for integrity, this is not necessary when reading from SD card) and program to flash.
You have to keep track of your destination address in flash to switch from Bank0 to Bank1 whenever necessary.

If your final application need ECC, than there is an option (Fapi_AutoEccGeneration) to program the main flash with the data and automatically calculate the corresponding ECC. This calculation is done by the Flash Wrapper itself (Hardware).

Hi Jean-Marc.  Thank you. I have uploaded the project with your suggested changes here:1881.SafetyMCU_Bootloader_Original_FlashIssue.zip

The good news is I got farther (flash erases Ok, and it then tries to program. The bad news is after just after programming to flash a few bytes using the Fapi_BlockProgram( programFlashBankNumber, programFlashDestination, (unsigned long) buf, ui32BytesRead);   which calls the Fapi_issueProgrammingCommand function. In this function is where it goes into this endless loop around the exception again (what used to happen in the erase).

see bl_flash.c . line 273 :

Fapi_issueProgrammingCommand((uint32_t *)dst,

(uint8_t *)src,

(uint32_t) bytes,

0,

0,

Fapi_AutoEccGeneration);

as is done with the UART version. I get the same wierd result of looping in sys_intvecs.asm.  

See below memory browser: a few bytes are programmed before it dies in ths endless loop. I updated bl_link.cmd as I did with the erase but the problem still happens:

Tammy,

You are facing the same exact problem.

Fapi_BlockProgram has to be located in RAM.
Yes you correctly modified the linker command file with:

     ..\Debug\bl_flash.obj (.text:Fapi_BlockProgram)

but you forgot to specify for bl_flash.c the advance runtime compile option to generate a section name for each function.

I did it and faced a size problem when the linker is trying to map all this code in RAM.
By chance I found another mistake, (I forgot to tell you that this morning) In the linker command file, the following line is not necessary:

//     ..\Debug\bl_sdcard.obj (.text)

We don't need the full sdcard.obj to be located in RAM, only some function listed as:

     ..\Debug\Biolase\source\sd_card.obj (.text:sdCardCatFlash)
     ..\Debug\Biolase\source\sd_card.obj (.text:bootloader_FlashProgramApplication)
     ..\Debug\Biolase\source\sd_card.obj (.text:bootloader_FlashApplicationRegion)
     ..\Debug\Biolase\source\sd_card.obj (.text:bootloader_FlashEraseApplication)
     ..\Debug\Biolase\source\sd_card.obj (.text:bootloader_FlashEraseSector)

So after these modification, I was able to program the first buffer. But your code exits from the

do
{

}      while(ui32BytesRead == sizeof(g_pcTmpBuf) - 1);

Tammy,

The only way I know to change a project name is to edit in the root directory of your project the following file:

.project

I usually copy the full project in a different directory then I edit .project

In .project, search for:
<projectDescription>
    <name>boot_uart_RM48_Tammy1</name>

boot_uart_RM48_Tammy1 is the name of the project as visible in your workspace. This name has to be unique in a given workspace.

Once you change it to let say boot_uart_RM48_Tammy2, save.

The project name does not have to match the project root directory name.

Concerning the size of the bin file, there is no information about sector size. So you have to read the bin file buffer after buffer.
When you execute iFResult = f_read(&g_sFileObject, g_pcTmpBuf, sizeof(g_pcTmpBuf),(UINT *)&ui32BytesRead);
ui32BytesRead contains the number of bytes read from file. It is normally sizeof(g_pcTmpBuf) but for the last read.