Postbuild Script applied to HIC MAX32625 release image not working Target: NRF52840

[0Grit]

This is no longer a blocking issue for us. We have gotten by using our NRF52840-DK backup plan.
I still want to capture it because I'm sure we will meet again.

We were attempting to MSD flash a custom target based on NRF52840 using the MAX32625PICO https://os.mbed.com/platforms/MAX32625PICO/

We used the post build script on the MAX32625 release firmware (REL v0254)

@trowbridgec & I consistantly were finding the following two issues depending on how we ran the script

• unable to get the MSD to enumerate (@loverdeg-ep did see DAPv2 and webusb)
• MSD enumerates but after "flashing" reports failure due to inability to reset target

I did not try to debug with pyOCD nor did I try flashing via webusb.

I still need to gather some notes on the script parameters and results we were seeing.

[brianesquilona]

@loverdeg-ep Can you provide some details as to when it was unable to enumerate the MSD against the MSD does enumerate? I guess what I want to find out is does these conditions happened on the same machine or these are 2 different cases. If it is, it is helpful to find out in what host machine it failed to enumerate the MSD.

[0Grit]

@trowbridgec has screencaps of our attempts and other info.

[trowbridgec]

We started out trying to use the MAX32625PICO board retargeted for the nRF52840. We downloaded DAPLink v0254 from the official GitHub release page and used the latest version of the tools/post_build_script.py script.

As there are many different input parameters, we tried many, many combinations, but didn't seem to get anywhere, which makes me think I'm missing something.

We then also switched to using the K20dx as an interface MCU since that is the HIC we wanted to use for our own board. We commandeered a FRDM-K64F dev board and cut the trace on the back to enable using the debug out SWD connector so that we could test with something until our board is in.

Here's a couple things we tried:

• family-id: 0x0001, 0x0002, 0x0003, 0x3602 (hex value for the Nordic nRF52 family)
• board-id: 0x0465, 0x4560
  • We were suggested to use a known nRF52840 board ID
  • 0x0465 is the board ID for the Laird BL654 (which is nRF52840 based)
• flash-algo-file: The latest .flm file (nrf52xxx.flm) from the nRF DFP from the Keil site (https://www.keil.com/dd2/pack/)
• target-ram-start: 0x20000000 based on the nRF52840 linker script from the mbed-os repo and the target.c file for the nrf5x family in the DAPLink repo.
• target-ram-end: 0x20008000 also based on the target.c file entry for the nrf52840
• bin-offset: 0x0000, 0x5000, 0x8000
• input binary file:
  • MAX32625: 0254_max32625__0x0000.bin, 0254_max32625_max32630fthr_0x0000.bin
  • K20dx: 0254_k20dx__0x0000.bin, 0254_k20dx_frdmk64f_0x5000.bin

From what I've seen, the builds we based on the .bin's not already targeting a specific board, we wouldn't get anything at all to show up when we'd plug in the USB (no USB MSD drive, nothing when running mbedls). If we based off of the board-specific .bin's, we'd get a USB MSD drive named DAPLINK, but copying a .bin/.hex to it for programming would hang and eventually time out saying it couldn't reset the target. Also, mbedls would list the board as the board that the .bin was originally designed for (as if it didn't take on our newly set board ID?).

@brianesquilona @flit Any assistance you can provide would be very welcome!

[0Grit]

@cederom any insight?

[trowbridgec]

bump

[40Grit]

@maclobdell

[0xc0170]

@brianesquilona @flit Any assistance you can provide would be very welcome!

I can't help here but will ask the team if they know

[brianesquilona]

As we can't really zoom as to where the issue is, I suggest that DAPLink should create a port for this board as a faster solution.

[0Grit]

@trowbridgec Is the K20 HIC based information you provided earlier still valid considering what we learned yesterday about that approach?

[trowbridgec]

Ah, no...I realized that we need to modify that circuit further to enable using the k20 on a FRDM board to debug an external chip (what we did enables debugging the target MCU from an alternate debugger than the k20).

I'll see if we can get that modification done on a FRDM board and re-test with the k20 bin.

[trowbridgec]

Using this article as a guide, it looks like we DID make the right modifications...cutting the J11 trace should allow the FRDM-K64F board's k20 to debug an external target, which makes sense: Freescale/NXP would want to make a path for customers to debug their custom boards via the dev kit.

[cederom]

i would recommend pyOCD for flashing and debug. this way you can use any DAPLink probe with any target!

the only need to build custom daplink is to have flash-algo compiled into daplink so it works with that drag-and-drop MSD/UMS feature.

pyOCD provodes faster flashig + gdb server over generic CMSIS-DAP HID enpoint to work with any target that is selected at pyOCD level (Cmsis Pack Manager provides dynamic support for hundreds of targets) :-)

[cederom]

i have some nRF52840DK boards so i can help where possible :-)

i remember SAM3 that is the default HIC for nRF family had some specific GPIO set to recognise the target nRF chip. also there were some issues with generic reset that could affect flashing. i have proposed some generic reset changes to overcome that. you probably want to use SOFTWARE RESET for nRF chips.. there also may be some chip specific reset/init quirks but dont remember exactly now.

anyway i have no keil license anymore to build the daplink. a gcc build would be nice to have. i have proposed long ago an automated way to build experimental user code with jenkins so users could get their daplink binary from a CI infrastructure. not sure if anything happened in this area..

anyway please try to use pyOCD first for flashing and debug that should solve the problem :-)

[40Grit]

Thanks for the tips!

The issue is the MSD flashing is used by green tea and there is no out of the box solution to do CI triggered target testing without it.

[cederom]

You may want to disable MSD completely.. something like this showed up recently in DAPLink.. this way you gain multiple targets support with any HIC over pyOCD and remove Greentea CI problem..? :-)

If the Greentea is still the problem even without the active MSD maybe you could modify the scripts just to skip the MSD tests? Maybe some invocation commandline switch? :-)

[40Grit]

I suppose that is our cue to make a PR to greentea; so that developers who purchases our new daplink board can at least use it for CI.

MSD is a non feature for us usually, but it is nice to provide it as an option for any of our clients who need the MSD convenience for devices without fota

[cederom]

DAPLink 254 introduces both:

• MAX32625 HIC.
• no MSD builds.

I would create no-MSD build and use HID / pyOCD for flash and debug to get a working solution quickly (it should work out of the box). In the meantime I would work on Greentea testing suite (so it works without MSD tests) and MSD functionality (in order to get full Greentea tests and for better end-user experience).

Please take a look at SAM3 HIC sources to see what details should come up in MAX HIC in order to work with nRF52 Target.

I have no experience with Greentea, sorry, but it looks like you can create/influence a test configuration using JSON file and commandline switches:
https://github.com/ARMmbed/mbed-os-tools/tree/master/packages/mbed-greentea#test-specification-json-format

[40Grit]

We now have an intern working on this and the effort to get greentea to support no MSD testing out of the box.

[0Grit]

@brianesquilona Result of our call the other day was that the Maxim HIC release was not functioning properly?