DAPLink
DAPLink copied to clipboard
ARMmbed
Can no longer flash new code after Error Message: Mutex lock failed
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 --
@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.
@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.
@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.
@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.
@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
@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.
@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.
@brianesquilona What is your suggestion for the best option moving forward?
@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
@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?
@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.
@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 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 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 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.
@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.
@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.
@brianesquilona Here are the contents of the fail.txt file:
error: The interface firmware FAILED to reset/halt the target MCU type: target
@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.
@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.
@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?
Add a family that adds target_before_init_debug and assert the target reset (swd_set_target_reset(1)) inside the family descriptor.
Can you provide some code and/or mention the file that I modify to help clarify this?
@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?
@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.
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 ;