I found micropython to be quite valuable in board bring-up stage. It is nice to be able to interactively test peripherals in repl, and these interactive sessions can be solidified in C code. This article about prototyping esp32 in micropython is great example: https://nick.zoic.org/art/lilygo-ttgo-t-watch-2020/
Yeah gdb is amazing tool. The micropython is few extra steps as you have to build the firmware for your target, and occasionally switch between proper FW and micropython FW. It still makes sense as you can do many things impossible in gdb.
You can define structs, loops and functions on the fly and execute them. You can build a complete driver in interactive session, first by poking around in registers and seeing that the HW reacts per spec, and then assembling correct operations into initialization function and updating function. All of this is throwaway code but it can save large amount of time.
Maybe non-critical systems could be left with the micropython implementation, but so far I haven't learned how to profile and optimize it to satisfaction.
Not on many microcontrollers, where you have no room for the debugging uart ports. I never had the luxury of gdb on my baremetal firmwares, only via selfwritten simulators or emulators. not qemu, qemu supports nothing. renode or unicorn are pretty good.
I'm not talking about running GDB ON the microcontroller (that's unlikely to be possible in most cases), but instead using OpenOCD (or JLinkGDBServer, or equivalent) to debug the running image via JTAG/SWD using GDB.
