mcuboot: HARD FAULT writing or reading flash on a stm32f0

I’m trying to swap images from slot1 to slot0 with boot_request_upgrade(0) and I’m having problems. When the mcuboot try to manipulate some region of flash like slot0, slot1 or scratch through flash_area_write or flash_area_erase I get this error:

***** HARD FAULT *****
***** Hardware exception *****
Current thread ID = 0x00000000
Faulting instruction address = 0xfffffffe

More precisely the error is happening after to call this function flash_write_protection_set(flash_dev, false).

I was wondering if my problem was that I couldn’t access flash for some reason, so I erased my memory flash and flashed a code with these statements and no errors occurred.

u8_t buff[] = "aaaaaaa";
int err            = flash_area_open(SCRATCH_ID, &fap);
if (!err) {
    printk("scratch -> fa_off: %X, fa_size: %X, fa_id: %d, fa_device_id: %d\n", fap->fa_off,
           fap->fa_size, fap->fa_id, fap->fa_device_id);
}
err = flash_area_write(fap, 0, buff, strlen(buff));
if (err) {
    printk("Error writing...\n");
} 
err = flash_area_erase(fap, 0, fap->fa_size);
if (err) {
    printk("Error erasing...\n");
}

After that, I got this same code and put it in the begin of mcuboot’s main and I got HARD FAULT again. So the same code results in HARD FAULT when I use it in mcuboot code and results in no error when I use it in a blank project.

I’m using the code in the branch master.

@EDIT: I’m using mcuboot for zephyr. @EDIT2: The function flash_write_protection_set(flash_dev, false) is inside of flash_area_erase and flash_area_write, I don’t call it directly. @edit3: This print “printk(“scratch -> fa_off: %X, fa_size: %X, fa_id: %d, fa_device_id: %d\n”, fap->fa_off, fap->fa_size, fap->fa_id, fap->fa_device_id);” is correct in both mcuboot and my blank project, the error is just in flash_area_write or flash_area_erase. Note that the flash_area_erase(fap, 0, fap->fa_size) is exactly the same statement that the mcuboot makes in boot_erase_sector(where my hard fault occurs) function, when the mcuboot is trying to erase the scratch region.

About this issue

Original URL
State: closed
Created 5 years ago
Comments: 20 (5 by maintainers)

Most upvoted comments

add_library(${KERNEL_LIBRARY}
  device.c
  errno.c
  fatal.c
  idle.c
  init.c
  mailbox.c
  mem_slab.c
  mempool.c
  msg_q.c
  mutex.c
  pipes.c
  queue.c
  sched.c
  sem.c
  stack.c
  system_work_q.c
  thread.c
  thread_abort.c
  version.c
  work_q.c
  smp.c
  )

On second thought, I think we should convert this line so that these files are only built using target_sources_ifdef(CONFIG_MULTITHREADING ...) or so as appropriate (e.g. for sem.c).

Otherwise this is just going to continue to break randomly – which is why I wonder how Andy Ross feels about this.

mbolivar on Aug 19, 2019

I am not a Zephyr developer, but MCUBoot runs without CONFIG_MULTITHREADING. The STM32 flash driver is using semaphores, and looking at the code I see z_impl_k_sem_give actually calls z_reschedule. I have no idea how that works when multi-threading is disabled (if it does at all). Also the nRF driver #ifdefs out the semaphores when no multi-threading is available: https://github.com/zephyrproject-rtos/zephyr/blob/master/drivers/flash/soc_flash_nrf.c#L69

So maybe one test you could do would be to define CONFIG_MULTITHREADING for testing purposes. Anyway I never used STM32 with Zephyr but if the flash driver is broken, it is broken for every STM32; it would be surprising, so I am probably wrong here!

The problem was exactly this! I enabled CONFIG_MULTITHREADING and it worked right away. Thanks for your help @utzig!

I’m closing this issue since the problem is solved.

lucaspeixotot on Aug 15, 2019