MMDVM HS DUAL HAT " failed to init device "with white low cost chinese board issue solved!

[F1RVC]

Hello, here is my solutions for upgrading the low cost white mmdvm dual hat pcb with failed to init device message:
Both of them need litle solders!

1st solution with a stlink usb adapter:
Using the st link to flash the bin file , here is a picture for wiring:


You can then use 3v3, gnd, clk and i/o for the stm32 clone by using a stlink usb adapter to flash with the bin file available here.

2nd solution, for using pi-star ssh : sudo pistar-mmdvmhshatflas hs_dual_hat
On the stm32 pin 20 (PB2) is the BOOT1 and should be to the ground, but the white chinese pcb does not have this connection,, without BOOT1(pin20) to ground , you will have the "failed to connect device " always when trying to flash the board (for me it was from 1.4.7 and to 1.5.2 and never could flash the pcb) so you have to do it yourself like this:

Then the issue "Failed to init device" should be an old story...
Hope this help.

[rlex]

I guess we're talking about those little aliexpress hotspots with rpi zero w?
I spent several hours looking at official instructions with no luck (and no data, since seller provided zero info) with same error, but then discovered i can just flash it (at least in w0chp pistar fork) with pistar-mmdvmhshatflash-custom.

hs_dual_hat target failed for me, mentioning my modem is locked and i need to contact supplier.

It came with following:

Nano_hotSPOT-v1.5.2 20201108 14.7456MHz dual ADF7021 FW by CA6JAU GitID #69d0879

After building custom fw i used sudo pistar-mmdvmhshatflashcustom firmware.bin, and viola:

Nano_hotSPOT-v1.6.0 20210919 14.7456MHz dual ADF7021 FW by CA6JAU GitID #192cba3

Here is my config for those models, just in case:

#if !defined(CONFIG_H)
#define  CONFIG_H
#define NANO_HOTSPOT
#define ENABLE_ADF7021
#define DUPLEX
#define ADF7021_14_7456
#define AD7021_GAIN_AUTO
#define STM32_USART1_HOST
#define ENABLE_SCAN_MODE
#define SEND_RSSI_DATA
#define SERIAL_REPEATER
#define SERIAL_REPEATER_BAUD 115200
#endif

(apparently there is 1.6.1 somewhere? But building from master gave me 1.6.0)

Tbh, won't be surprised if those boards come in different versions, locked and unlocked, and other stuff. But just adding that here in case someone might google it, since never versions of w0chp pistar requires 1.6 fw (apparently not true, only needed for m17 mode)

[W0CHP]

(apparently there is 1.6.1 somewhere? But building from master gave me 1.6.0)

That's correct - my colleague, G4KLX, is now maintaining MMDVM_HS: https://github.com/g4klx/MMDVM_HS - and v1.6.1 is the latest.

[...] since never versions of w0chp pistar[sic] requires 1.6 fw.

This is false. *WPSD has no firmware version dependency. I just wanted to clarify this misinformation. We have plenty of users running v1.5.2, and even v1.4.17.

The use of the esoteric M17 protocol/mode, does, however, require MMDVM firmware of at least 1.6.0.

How do I know all this? I'm the author of WPSD and an M17 team & board member. :^)

[rlex]

This is false. *WPSD has no firmware version dependency.

Interesting. After completely reflashing my dated hotspot with new image i started to get

Received a NAK to the SET_CONFIG command from the modem"

and MMDVMHost crashed.

Which went away after flashing 1.6

And thanks for your pistar fork!

[W0CHP]

Received a NAK to the SET_CONFIG command from the modem

Did you happen to have M17 (or FM or AX.25) mode(s) enabled? If so, that error would make sense, since the MMDVMHost shipped with WPSD is aware/supports those modes, but MMDVM_HS_HAT v1.5.2 does not (all other modes are supported in v1.5.2, though.).

And thanks for your pistar fork!

My pleasure, and thanks for using WPSD! 💯

[rlex]

Did you happen to have M17 (or FM or AX.25) mode(s) enabled? If so, that error would make sense, since the MMDVMHost shipped with WPSD is aware/supports those modes, but MMDVM_HS_HAT v1.5.2 does not (all other modes are supported in v1.5.2, though.).

nope, only DMR and POCSAG. Maybe firmware that came from shop wasn't straight from that repo and had some quirks inside? Sadly, i hasn't dumped it before flashing new one.

[mytechguyri]

Could the OP possibly provide more detail as to which pin gets connected where on the ST-Link from those two test points on the board? I see you soldered it to a header, but what wires on the ST-Link are you connecting to each pin of the header?

[mytechguyri]

Confirmed, the fix of connecting the boot pin (pin 20) to ground fixes these boards... If anyone is interested, I found a guy who can do the fix for just $10 (I don't have a steady enough hand to do it myself, so I sought out someone to do it for me.).. now running FW 1.6.1 on this board, and it takes firmware updates as it should through the normal pi-star or wpsd firmware update process.

[iw0red]

Connecting the boot pin 20 to ground fixes the programming issues. Thank you.
IW0RED