Kinetis Flash Tool with an Update image failure (cumulative write)

[JulianS]

Hi all,

I successfully ported the KBOOT V2 from the TWR-MKV58F22 Bootloader to my MKV58F1M0VLL24 MCU on a custom board (Using KDS V3.2). Neraly everything is working as expected, except a strange update-behaviour with the KinetisFlashTool.

Updating my application binary to the target address sometimes succeeds and sometimes fails with the kStatusMemoryCumulativeWrite errormessage. I observerd this behaviour especially then, when there is already an application binary on the target flash, which I am going to erase and replace with my new application (in my example, the new application binary is the same binary as the one already placed on the flash... I just want to test everything to avoid later upcoming bugs, so the content of my binary shouldn't be of interest). When the error message occurs, I try to erase the whole flash memory in order to prevent cumulative memory writing as mentioned in the MCU's reference manual. Since now, every time I erased the whole memory, the KinetisFlashTool just responded with "Erase all memory of internal flash. Completed!", so I expected the erasing to be successful.

Nevertheless after trying to Update my "new" application binary to the "freshly erased flash memory", the same cumulative write error occurs. The only workaround for this problem is to reset the device via the KinetisFlashTool followed by normally clicking the Update Button...

After this procedure, when I reset the device, connect to KinetisFlashTool and try to Update the application binary again, the already mentioned error occurs again. And again, erasing the whole flash memory doesn't help at all.

Since I didn't found any similar question about this, I am wondering if I am missing any important step while updating my application binaries?

I would really appreciate some help to understand what is going wrong with the updating procedure on my MCU...

With kind regards,

Julian

[kerryzhou]

Hello Julian Schork,

    When you use the KinetisFlash Tool, please select the erase all to unlock, just like the following picture:

  Then try it again.

If you still have problem, please also attach the problem picture about your kinetisFlash Tool.

Have a great day,
Kerry

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[JulianS]

Hello Kerry Zhou,

thank you for your quick response!

Unfortunatelly using the "Erase All to Unlock" Feature doesn't solve the problem. As mentioned before, even erasing the whole memory (starting from application address) before updating my binary doesn't solve this issue. I attached a screenshot of the Kinetis Flash Tool where the error occured.

Restarting the device via the "Reset" Button in the Kinetis Flash Tool solves the issue for the moment, but the next time I am trying to update my binary, the same error occurs. Additionally, closing the KinetisFlashTool also resets the device, so starting the KinetisFlashTool again causes the needed reset to update my binary as well. I attached you another two pictures where I first ran into the error and then solved the issue as mentioned.

Do you have any further suggestions to solve this issue?

With kind regards,

Julian Schork

[kerryzhou]

Hello Julian Schork,

    It seems your porting code missed something.

   Could you do the debug in your bootloader? then check when the problem happens, where the code is stopping?

Have a great day,
Kerry

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[JulianS]

Hello Kerry Zhou,

Thanks again for your support.

I found something really peculiar while debugging the bootloader up to the point where the "mem_is_erased"-Check fails.
In the function mem_is_erased (memory.c), the bootloader checks whether the flash from the application start address is really erased (all the bits set to 1).

Considering the General Registers, the Memory and instructionswise stepping through the code, the following occured:

in the disassembly at 100059ac, the address is loaded to the r3 register which you can see in the General Registers (lighted yellow in the picture below)

in the next step at Disassembly 100059ae the value at the address, stored in r3 should be loaded to the r3 register. This is where the problem occurs. If you take a look at address 1000A000 in the lower section of the picture, you see that the value is FFFFFFFFF... But if I take one step further:

You can see that in r3 the value 0x0 is stored. Of course this causes the condition (*start != 0xFF) to be true, ending in the isMemoryErased = false problem.

Additionally I want to mention that taking a look at the sourcecode at the same time (e.g. with the help of the Variables View), the variable content seems correct, because start = 0x1000a000 and *start = 0xff. Nevertheless the condition is said to be true... (in the below picture, the "Variables View" shows the source code variables at the debug-point in the picture above at isMemoryErased = false;)

Does this make any sense to you?

I already checked the errata-sheet, but there is no similar issue...

With kind regards,

Julian Schork

[kerryzhou]

Hello Julian Schork,

    Thank you for your effort.

   Now, check these points:

1. the IDE project optimization

   Select the optimization level to none, and try again.

2. Check the C code address, and start, whether the address is correct. Do it step by step, whether the address will jump to the abnormal area.

3. After build, please check the bootloader code size, make sure it is not exceed to the application address.

Any updated information, please let me know!

Have a great day,
Kerry

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[JulianS]

Hello Kerry Zhou,

I really appreciate your fast support!

The compiler optimization was already turned off...

After building the bootloader(debug build), the bootloader codesize is at 37.380 bytes (text-section for application code):

arm-none-eabi-size --format=berkeley "MKV58F1M0VLL24_Bootloader.elf"
   text       data        bss        dec        hex    filename
  37380        364       5120      42864       a770    MKV58F1M0VLL24_Bootloader.elf

By way of comparison, the bootloader codesize of the release build is way smaller because of compiler optimization in size (-Os):

arm-none-eabi-size --format=berkeley "MKV58F1M0VLL24_Bootloader.elf"
   text       data        bss        dec        hex    filename
  22620        356       5088      28064       6da0    MKV58F1M0VLL24_Bootloader.elf

Nevertheless, the Problem occurs in both builds.

By the way, this is the MEMORY specification of my bootloader:

MEMORY
{
  m_itcm                (RX)  : ORIGIN = 0x00000000, LENGTH = 0x00010000
  m_interrupts          (RX)  : ORIGIN = 0x10000000, LENGTH = 0x00000400
  m_flash_config        (RX)  : ORIGIN = 0x10000400, LENGTH = 0x00000010
  m_text                (RX)  : ORIGIN = 0x10000410, LENGTH = 0x000FFBF0
  m_data                (RW)  : ORIGIN = 0x20000000, LENGTH = 0x00020000
  m_ocram               (RW)  : ORIGIN = 0x2F000000, LENGTH = 0x00010000
}

and this is the one for my application:

MEMORY
{
  m_data                (RW)  : ORIGIN = 0x00000400, LENGTH = 0x0000FC00
  m_interrupts          (RX)  : ORIGIN = 0x1000A000, LENGTH = 0x000003C0
  m_bca                 (RX)  : ORIGIN = 0x1000A3C0, LENGTH = 0x00000040
  m_text                (RX)  : ORIGIN = 0x1000A400, LENGTH = 0x000F5C00
  m_data_2              (RW)  : ORIGIN = 0x20000000, LENGTH = 0x00020000
  m_data_3              (RW)  : ORIGIN = 0x2F000000, LENGTH = 0x00010000
}

In addition, BL_APP_VECTOR_TABLE_ADDRESS is set to 0x1000A000, which suits the address stated in the Kinetis Flash Tool.

Do you see any further possible problem sources?

With kind regards,

Julian Schork

[kerryzhou]

Hello Julian Schork,

     In debug mode:

    Relocate the app address to 0X1000C000, because the generate code size is a770 , it is larger than 0XA000.

  Please modify both bootloader and app address to 0X1000C000, then try agian, and debug, whether the former problem still happens, and also check the mem_is_erased function, whether the address jump still abnormal?

Have a great day,
Kerry

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[JulianS]

Hello Kerry Zhou,

I adapted the app address to 0x1000F000 to give the bootloader more space than even needed. Sadly this doesn't change anything in the behaviour while updating the application binary...

Bootloader Memory specification:

MEMORY
{
  m_itcm                (RX)  : ORIGIN = 0x00000000, LENGTH = 0x00010000
  m_interrupts          (RX)  : ORIGIN = 0x10000000, LENGTH = 0x00000400
  m_flash_config        (RX)  : ORIGIN = 0x10000400, LENGTH = 0x00000010
  m_text                (RX)  : ORIGIN = 0x10000410, LENGTH = 0x000FFBF0
  m_data                (RW)  : ORIGIN = 0x20000000, LENGTH = 0x00020000
  m_ocram               (RW)  : ORIGIN = 0x2F000000, LENGTH = 0x00010000
}

Application Memory specification:

MEMORY
{
  m_data                (RW)  : ORIGIN = 0x00000400, LENGTH = 0x0000FC00
  m_interrupts          (RX)  : ORIGIN = 0x1000F000, LENGTH = 0x000003C0
  m_bca                 (RX)  : ORIGIN = 0x1000F3C0, LENGTH = 0x00000040
  m_text                (RX)  : ORIGIN = 0x1000F400, LENGTH = 0x000F5C00
  m_data_2              (RW)  : ORIGIN = 0x20000000, LENGTH = 0x00020000
  m_data_3              (RW)  : ORIGIN = 0x2F000000, LENGTH = 0x00010000
}

BL_APP_VECTOR_TABLE_ADDRESS set to 0x1000F000...

Kinetis Flash Tool targer address: 0x1000F000

I also checked he mem_is_erased function... the behaviour is still abnormal.

With kind regards,

Julian Schork

[kerryzhou]

Hello Julian Schork,

    When you debug mem_is_erased , could you check the address, and start in the function mem_is_erased, and give me the step by step, until the problem happens picture?

Have a great day,
Kerry

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[JulianS]

Hello Kerry Zhou,

these are the step by step screenshots when the error occurs:

Again I would like to mention, that this error doesn't occur after resetting the device and connect it again... Only if I update the binary, connect again to the bootloader and try to update again, the error occurs until I again restart the device.

With kind regards,

Julian Schork

[kerryzhou]

picture 12 and picture 13 is really very strange.

  start address is 0x1000f000, the data is 0xff, but in the asm, it makes the data as 0.

I also need time to do the consideration.

  Could you share your modified bootloader to me?

Have a great day,
Kerry

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[JulianS]

Hello Kerry Zhou,

do you have any news regarding the flashing-problem?

With kind regards,

Julian Schork

[kerryzhou]

Hello Julian,

    This is my debug result:

Please check your problem like me, whether both memory and variable is 0xff.

Waiting for your reply!

Have a great day,
Kerry

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[JulianS]

Hello Kerry,

thanks for your endurance with this problem!

This is a screenshot, when the error occurs...

I will now test if the same error occurs while using blhost.

With kind regards,

Julian

[kerryzhou]

Hi Julian,

    Thank you for your updated information, I think the root problem will be turn out in the near future, please follow my step, and give your problem debug picture like me:

1. Use C debug enter mem_is_erased function, then choose instruction stepping mode.

I need to see the registers window, memory window and variables window, please do it like me.

Step to asm code:

 ldr r3, [r7, #12]

This code means, it will put r7+12 data to r3.

You can find in my picture r7 is 0X200014E0, 0X200014E0+12=0X200014E0+0x0c, in the memory, you can find the bytes data in 0X200014EC is: 0X1000F000, it is just the address which you want to read, the correct data is 0XFF.

Now, I need to check your RAM data which contains the flash address.

Which I am afraid is your RAM 0X200014EC already put in the wrong flash address.

2. Step into

You can find, just as we expect, the r3 is the flash address 0x1000f000 now.

3, Still step into

You can find r3 is 0XFF now.

Please do this asm debug and check the Rn register now, just like the picture on my side.

This is very important to your question.

Waiting for your debug result!

Have a great day,
Kerry

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[JulianS]

Hello Kerry,

sadly, this is exactly the point, where my MCU is behaving bizarre... here are the steps you need:

Step 1:

Step 2:

Step3:

I hope this helps to get any further...

With kinds regards,

Julian

[JulianS]

Hello Kerry,

here is my test result with the blhost.exe:

C:\+sentronics20\+Hardware\+Bootloader\NXP KBOOTv2 for MKV58F1M0VLL24\bin\Tools\
blhost>blhost -p COM5 -- flash-erase-all
Ping responded in 1 attempt(s)
Inject command 'flash-erase-all'
Successful generic response to command 'flash-erase-all'
Response status = 0 (0x0) Success.

C:\+sentronics20\+Hardware\+Bootloader\NXP KBOOTv2 for MKV58F1M0VLL24\bin\Tools\
blhost>blhost -p COM5 -- write-memory 0x1000F000 SLD.bin
Ping responded in 1 attempt(s)
Inject command 'write-memory'
Preparing to send 90516 (0x16194) bytes to the target.
Successful generic response to command 'write-memory'
(1/1)1%Data phase write aborted by status 0x2712 kStatus_AbortDataPhase
Response status = 10203 (0x27db) kStatusMemoryCumulativeWrite
Wrote 992 of 90516 bytes.

As you can see, the same error occurred again. I also set the breakpoint to the memory_is_erased to see again, that in r3 the value is 0x0 instead of 0xff...

With kind regards,

Julian

[kerryzhou]

Hi Julian Schork,

    Please comment SCB_EnableICache(); and SCB_EnableDCache(); in system_MKV58F24.c, then try it again, whether the problem will happen or not?

Waiting for your reply!

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[JulianS]

Hello Kerry,

what do you exactly mean by "By the way, do you meet this problem in the TWR-KV58 on your side?" ?

I don't have the TWR-KV58 Module for evaluation. I'm just working with the custom board.

Here is my KDS version:

And finally:

YES, commenting those two functions in system_MKV58F24.c fixes the issue !!

Especially not enabling the data cache, fixes the issue... the instruction cache doesn't seem to be part of the problem.

Thank you again very much for your effort!

Now I try to understand, why I have to disable the data-cache to avoid the flashing problem.

Does this issue trace back to the ARM cortex m7 core?

I wonder if there's a way to use the cache properly for my bootloader in general and my application as well...

With kind regards,

Julian

[kerryzhou · Accepted solution]

Hi Julian Schork,

    That's really very good to hear it works on your side.

    I get the solutions from the KBOOT2.0 owner, and I have been told that kboot2.0 don't support the cache now, so customer need to disable the cache, otherwise, it will cause the problem which you are meeting.

    You just need to comment it!

Have a great day,
Kerry

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------