Can no longer flash new code after Error Message: Mutex lock failed

[cwq9999]

I received the error below on my device that uses the STML476 MCU. The device uses an LPC11U35 for drag and drop flash programing. The drag and drop update no longer works since this error is occurring. Is there a way to reset/clear this error to allow reprograming?

++ MbedOS Error Info ++
Error Status: 0x80020115 Code: 277 Module: 2
Error Message: Mutex lock failed
Location: 0x8016525
Error Value: 0xFFFFFFFA
Current Thread: Id: 0x20003938 Entry: 0x801DEA9 StackSize: 0x1000 StackMem: 0x20002938 SP: 0x20017F40
For more info, visit: https://armmbed.github.io/mbedos-error/?error=0x80020115
-- MbedOS Error Info --

[brianesquilona]

@cwq9999 can you confirm what Daplink version are you using and what binary? Also, you can try, holding the reset button of the target while dragging the binary into the Daplink drive, just for quick test.

[cwq9999]

@brianesquilona I'm not 100% sure of the Daplink version, where is that information stored in the DAPLINK folder? The binary is a custom binary that we generated in late 2016/early 2017. I will try to test with the reset pin active.

[brianesquilona]

@cwq9999 Did the reset pin allowed the target to be flashed? Can you try the newest version of Daplink, there were some fixes on reset handling on some targets.

[cwq9999]

@brianesquilona The reset pin didn't seem to allow the target to be flashed. I will try rebuilding the LPC bin with the latest Daplink to see if that might resolve the issue.

[brianesquilona]

@cwq9999 I found an issue with ST targets not able to recover on bad binaries, it has something to do with configuring debug on reset, can you try this binary if you are using mtb_wise1570 (lpc11u35 + stm32l486).
lpc11u35_mtb_wise1570_if_crc.zip

[cwq9999]

@brianesquilona Thanks for taking a look into this and confirming this reset issue. Unfortunately I'm not using the mtb_wise1570 but rather a custom combination of the lpc11u35 + stm32l476. I've been trying to recompile the DAPLink but found that the latest DAPLink seems to need a full version of Keil so have been trying to build with the mbed cli, but having some issues with that too.

[brianesquilona]

@cwq9999 currently only arm compiler is supported by Daplink, and this will also require license.

Pushing the target button might require some timing, it needs to be asserted only during setup before drag and drop, and release during actual flashing.

[cwq9999]

@brianesquilona What is your suggestion for the best option moving forward?

[brianesquilona]

@cwq9999 you can still try pyocd to reflash it, just that you will need to add your board in the pyocd database. https://github.com/mbedmicro/pyOCD

[cwq9999]

@brianesquilona thank you for that recommendation. Just to clarify on building a new bootloader binary to fix the issue long term, that will require an ARM compiler license? Are there any options for a one time build?

[cwq9999]

@brianesquilona. I downloaded and installed a trial version of the ARM Development Studio and tried importing the Keil project that I generated per the instructions in the DAPLink readme file on GitHub. However, I couldn't get the project to build. Perhaps the keil project files are compatible. If there are instructions on how to rebuild the binary in ARM Development Studio that would be great and I could then test (in the next 30 days) any changes you may have made in the .bin you sent earlier.

[brianesquilona]

@cwq9999 you can try the mbedcli approach for this, just make sure that you can compile with armcc, al you need is to set the path of the compiler.

[brianesquilona]

@cwq9999 lpc11u3_stm32l476rg_if should be lpc11u35_stm32l476rg_if

[cwq9999]

@brianesquilona I was able to get the project to compile. Is there a new version of DAPLink that will address the issue with ST targets not able to recover on bad binaries? If so I will pull that latest version and try building the project again. I also see there is a lpc11u35 with a stm32l476rg mtb board in the works so perhaps when that version get committed the issue may be resolved? Thanks!

[brianesquilona]

@cwq9999 you can try #567

[cwq9999]

@brianesquilona Sounds great. I will give that a try. Thanks!

[cwq9999]

@brianesquilona I updated the DAPLink after the fix to the STM family that was made. Now I seem to be having an issue when I use code like the code below. I get a failed to flash error for some reason. It does appear to reset the MCU, but doesn't seem to actually flash the code. Is this a know issue?

int main() {
    pc.baud(115200);
    
    //Do something
     
    wait(osWaitForever); 

}

[brianesquilona]

@cwq9999 Did you updated to the latest codes, and enable the under reset PORT_BOARD.md

[cwq9999]

@brianesquilona I updated to the latest code as of Jan 28th. Should I use a newer release? I think I added the enable under reset, but I will double check that. Thank you for the suggestion and quick feedback.

[cwq9999]

@brianesquilona I pulled the latest version and ensured that enable under reset is set (I think) based on the PORT_BOARD.md. The issue still persists. So to recap what is happening. I'm using a LPC11u35 with a STM32L476RG.

Case 1: If "while(1){}" is placed at the end of main. I can drop a new .bin for the L476 at anytime after power up, but this doesn't automatically reset the L476 and requires a manual power cycle of the device. After the power cycle the new firmware is operational.

Case2 : if "wait(osWaitForever);" is placed at the end of main. I can drop a new .bin for the L476 anytime before the "wait(osWaitForever)" is reached. However once the wait(osWaitForever) statement is reached, when a new .bin is dropped the L476 automatically resets and the new firmware doesn't update and I received a failed flash error file on DAPLink.

[brianesquilona]

@cwq9999, what was the error in the DAPLink drive, can you paste the contents of FAIL.TXT or ASSERT.TXT, another test that you can do, is, you can use uvision, and try to program your board with under Reset in Connect & Reset option.

[cwq9999]

@brianesquilona Here are the contents of the fail.txt file:

error: The interface firmware FAILED to reset/halt the target MCU
type: target

[cwq9999]

@brianesquilona Would the latest commit "Correct order of flash algo call sequence" have an impact on the issue that I'm having? I am currently working on testing via Keil as well.

[brianesquilona]

@cwq9999, it should not have as most of the flash algo have blank uninit. But please verify, the error will be easy to spot like uninit error.

// ERROR_UNINIT
"The interface firmware FAILED to uninitialize the target MCU",

Let me know how the keil under reset do. I may have one more simple suggestion, but it includes adding a family.

[cwq9999]

@brianesquilona ok sounds good. Thank you for the feedback. I will let you know about the Keil change and also update to the latest commit. What is the other simple suggestion you have?

[brianesquilona]

Add a family that adds target_before_init_debug and assert the target reset (swd_set_target_reset(1)) inside the family descriptor.

[cwq9999]

Can you provide some code and/or mention the file that I modify to help clarify this?

[cwq9999]

@brianesquilona I tried the latest version of DAPLink and no change. I also tried Erasing the flash via Keil. I am able to erase the flash anytime in the program until I hit the end of main at wait(osWaitForever);

These are the errors Keil gives:

"PDSC: Sequence Execution failed"
"Error: Flash Erase failed - Target DLL has been cancelled"

Could you provide some additional information for the addition of another family that adds target_before_init_debug and assert the target reset (swd_set_target_reset(1)) inside the family descriptor?

[cwq9999]

@brianesquilona an update. I was able to erase the flash using keil if I set the debug "DAPLink" to connect "under reset" and deselect all of the check box options under the Debug connect and reset options section.

[brianesquilona]

sample files are in source/family/*/target_reset*.c

Your family file will look like this, and include it your project

static void target_before_init_debug(void)
{
swd_set_target_reset(1);
}

const target_family_descriptor_t g_test_family = {
.family_id = 0,
.target_before_init_debug = target_before_init_debug,
};

const target_family_descriptor_t *g_target_family = &g_test_family ;

[cwq9999]

@brianesquilona Thanks for this example code. Does the target_reset.c need to be referenced or called from any of the other files after creation?

[cwq9999]

@brianesquilona Also I notice that you have an asterisk at the end of the the target_reset*.c Does that need to be unique or can I just call the file target_reset.c? I'm assuming unique due to the asterisk but just want to clarify. Also are there any place holders in the family file code you provided?

[cwq9999]

@brianesquilona I was able to get some version of this to compile, but that didn't allow any firmware to be flashed at anytime. Perhaps I needed to adjust the target test family or something?

[brianesquilona]

@cwq9999 I got a fast code modification just to verify if this will work

Just insert
swd_set_target_reset(1);
osDelay(2);
in L805

If this works, remove the delay, if not, you might have to investigate if you are really asserting reset in your target from swd_set_target_reset(1) call.

[cwq9999]

@brianesquilona Thanks for this information. I tried this and received this error:

The operation can’t be completed because an unexpected error occurred (error code 100006).

Where is the swd_set_target_reset() function located so that I can further debug this? I assume this is just asserting the NRST pin on the target?

[cwq9999]

@brianesquilona Is it possible to modify the DAPLink setup to mimic the method that Keil uses to erash the flash with "under reset" mode before flashing the new file? Perhaps this is what is trying to happen, but not sure I understand why this works in Keil but not in the DAPLink binary.

[cwq9999]

@brianesquilona Is there some documentation for checking to see if swd_set_target_reset(1) call is working properly? Also is there a way to mimic the keil method of erase the flash under reset which seems to work using the DAPLink protocol?

[brianesquilona]

https://github.com/ARMmbed/DAPLink/blob/master/source/target/target_family.c#L146 shows the logic. By default it is just asserting nRESET_OUT, so you can check if this pin is connected and the reset logic is correct

[cwq9999]

@brianesquilona is there a schematic that we can use to validate our board wiring? Also this design has worked well for over 3 years. Why would this problem start occurring now with mbed os 5?

[cwq9999]

@brianesquilona We double checked our schematic against similar board designs including the mbed daplink hdk and everything looks normal.

Then I tried the following:
swd_set_target_reset(0);
osDelay(2);
in L805

This did something interesting. When I drop a firmware image onto DAPLink the MCU seems to have shutdown but not restarted (when "wait(osWaitForever);" is hit otherwise flashing works normally. Then if I wait for DAPLink to reappear and drop the firmware image again, it works this time.

Any idea as to why this is happening and does this provide any insight into a proper fix?

Thanks!

[cwq9999]

@brianesquilona @sg- Curious if there is anything else we can try to resolve this issue.