hal: K20 - Flash configuration field issue

[0xc0170]

Hi,

I noticed the K20 device does not define any flash configuration. Some tools might ignore flashing the device or overwrite it to protect the chip.

Here's an example of the flash config I created, added to isr.rs for k20

#[link_section=".flash_configuration"]
#[allow(non_upper_case_globals)]
#[no_mangle]
pub static FlashConfigField: [int, ..4] = [
    0xFFFFFFFF,
    0xFFFFFFFF,
    0xFFFFFFFF,
    0xFFFFFFFE,
];

And snippet from the layout.ld file:

SECTIONS
{
    .vector : ALIGN(4)
    {
        FILL(0xff)

        KEEP(*(.isr_vector))
        KEEP(*(.isr_vector_nvic))
    } > vectors

    .flashcfg : ALIGN(4)
    {
        KEEP(*(.flash_configuration))
    } > flash_config

The only way I made it functional was by adding it into k20 isr file (that file is linked separately which does the trick for linker not to remove it, same should be applied to flash protection bits).
, which I don't find as a proper solution. Any suggestions ?

Regards,
0xc0170

[farcaller]

@bgamari, can you please advice on this?

[bgamari]

That reminds me: I sent this message to zinc-dev a few weeks ago but it bounced as I sent it from the wrong account.

The K20 has a FLASH configuration block at 0x400 that can brick the
device if improperly written. Currently we deal with this with,

MEMORY
{
  VECT (R)      : ORIGIN = 0x00000000, LENGTH = 0x3FC  /* Vector area */
  FIRC (R)      : ORIGIN = 0x000003FC, LENGTH = 4      /* Custom IRC user trim */
  FCFG (R)      : ORIGIN = 0x00000400, LENGTH = 16     /* Flash config */
  FLASH (RX)    : ORIGIN = 0x00000410, LENGTH = 32K - 0x410
  RAM (WAIL)    : ORIGIN = 0x20000000 - 8K / 2, LENGTH = 8K
}

That is we don't start the actual FLASH region until well after the
configuration block. While at first glance this appears to be the safe
thing to do, I learned today that it interacts very badly with OpenOCD
which will,

• Erase the sector starting at 0x400 and whatever following sectors
  the program needs
• Write the text starting at 0x410

Note that 0x400 to 0x410 was never written and therefore remains
0xff. This means the chip will come up secured after the next reset.

Arguably the fact that OpenOCD's write algorithm modifies bytes that
weren't requests is a bug. Putting this aside for a moment, it
nevertheless seems like a bad idea to leave the contents of the FLASH
configuration block up to chance.

Moreover, the binaries currently produced by Zinc won't even be accepted
by some JTAG implementations as our sectors don't begin on a
sector-aligned address.

Ideally I would like to be able to keep FCFG as a separate memory
block. Unfortunately, OpenOCD writes things to FLASH section at a
time. Since the FLASH configuration section and .text will reside in the
same FLASH sector one will erase the other when written.

This is generally unfortunate but I really don't have time to fix this
properly at the moment (which would probably involve making OpenOCD's
writing algorithm more sane). For that matter I don't really have any
ideas for platform-independent workarounds. Currently I'm just carrying
the attached hack.

Anyone have any brilliant ideas?

[0xc0170]

Thanks for a reply. I was able to make it work if that flash algo is part of isr file for a reason mentioned above in my first post. Any ideas how I to make it link separately ?

@bgamari as you noticed the flash config is evil sometimes, I had to fix locking in pyOCD and even in mbed cmsis dap interface. Each implementation using own mechanism, like jlink has safe mode (won't overwrite those registers, or regular where it allows writing them).

[bgamari]

@0xc0170 I think the right way to do this is to teach Zinc about the FLASH configuration region somehow. That being said, it's not clear how to do this without losing the first sector of FLASH or making the result dependent upon the JTAG implementation doing the right thing in the face of non-sector-aligned sections (which at very least OpenOCD gets wrong).

[0xc0170]

I don't think your assumption is correct, in the above post. I don't understand the statement "without losing the first sector of FLASH". Currently, the sector is empty, is not even in the elf file, which results in writing 0x0 to FCG. Look at the produced binary, it has 0x0 at 0x400-0x410.

Leaving the result to implementation (not only JTAG but others) is not an option. I was there, locked few chips 😯

I'll send a pull request with the fix which means FCG definition will be in k20 isr file. You can send comments there once you see what I have changed thus we might come up with nicer solution (my rust is currently limited :) )

[bharrisau]

From memory, an empty sector is actually writing 0xFF as erased flash is
0xFF.

@0xc0170 Apparently the issue with the linker file as described is that
some tools don't handle 2 binary sections using the same sector of flash.
They erase the sector, write the section, then go on to the next section
(erasing the sector again). My suggestion was to use the srec format when
flashing, but we need the ELF when debugging.

On 3 November 2014 16:29, Martin Kojtal notifications@github.com wrote:

I don't think your assumption is correct, in the above post. I don't
understand the statement "without losing the first sector of FLASH".
Currently, the sector is empty, is not even in the elf file, which results
in writing 0x0 to FCG. Look at the produced binary, it has 0x0 at
0x400-0x410.

Leaving the result to implementation (not only JTAG but others) is not an
option. I was there, locked few chips [image: 😯]

I'll send a pull request with the fix which means FCG definition will be
in k20 isr file. You can send comments there once you see what I have
changed thus we might come up with nicer solution.

—
Reply to this email directly or view it on GitHub
#212 (comment).

[0xc0170]

@bharrisau What tools? I haven't seen any report to openOCD in that case. KSDK IDE from Freescale uses openOCD and they define the sectors same as it is in zinc right now. For example, in pyOCD gdb implementatioin, the data are collected per sector, means for k20 0x400-0x800 gets flashed properly whatever number of memory sections are defined in the sector.
I personally don't believe their (openOCD) implementation is erasing/writing by sections as you described, but by flash sectors.

I was using openOCD for some of my projects, never got this problem. I can get the newest openOCD and test it again.

True for gdb, it should write 0xFF, the output in binary is 0x0 though so if I use binary for flashing, it would get secured. Therefore is recommended to define FCG always, to be on safe side.

Update: I remember I had this type of problem in pyOCD, where the offset was not accounted for. Probably is the same problem in openOCD. To test this theory, we can test openOCD with my FCG patch.

[bharrisau]

@bgamari reports the following (we discussed this very thing on the mailing list circa 19th October).

Right, but again if we put this into a .fcfg section then OpenOCD does
the following when writing to FLASH (if .fcfg and .text share a sector),

  1. Clear sector starting at 0x400
  2. Write .fcfg
  3. Clear sector starting at 0x400
  4. Write .text

[0xc0170]

I don't know what elf you tried to flash, what commands did you use, what version of openOCD , so the problem might be somewhere else, not in openOCD.

Normally, it should collect all memory sections within same page size (= flash bank). I have glanced at openOCD implementation, looks to me they do what I anticipated.

Code snippet from flash_write (wrapper for calling _unlock) which is called when packet is 'FlashDone':

int flash_write_unlock(struct target *target, struct image *image,
    uint32_t *written, int erase, bool unlock)
...
some code here....
00607         /* collect consecutive sections which fall into the same bank */
00608         section_last = section;
00609         padding[section] = 0;
00610         while ((run_address + run_size - 1 < c->base + c->size - 1) &&
00611                 (section_last + 1 < image->num_sections)) {

I'll look at it further this evening and read all the mailing list to be up to date. Thanks for your inputs.

[0xc0170]

What cfg are you using for openOCD? I tried k40 and k60. but it fails (load fails right after flash cfg section). I suspect the problem is in my cfg file. Not in the openOCD as I tested today other kinetis targets with same memory layout as K20 and was functional.

I tested it with pyOCD (that one supports currently only cmsis-dap transport), working like charm 👍

[0xc0170]

'This should be now resolved.