2026-04-18 2:12 PM
I've built at least a dozen boards using the same communication interface -- a custom debug monitor for communication through stlink -- all on stm32l42x processors. The debug monitor looks roughly like the following code. Although the macros are for ChibiOS, their purpose should be clear.
Basically, the host software, after attaching to the debug interface, communicates by passing small commands through DCRDR and getting 32 bit results (which may be memory addresses) in DCRDR. The DEMCR is used for triggering the monitor interrupt and the MON_REQ bit is used as a semaphore.
This has worked great until now. I received prototypes of a new design. Reading/writing of DCRDR works fine, but writes to DEMCR have no effect. I can debug the code on the board with gdb, and I can write test code that triggers the monitor interface running on the board and even stop in the monitor with a breakpoint, but I don't seem to be able to write a value to DEMCR through stlink that triggers the monitor. The same code works on an earlier prototype board (I debug on something that looks like custom nucleo) with exactly the same external peripherals with the same pin configurations.
The actual board that is failing to thrive is a tiny data logger -- 0.2g 9x20mm -- so there are no pins beyond the stlink interface.
I'm at a loss on how to diagnose the problem and am looking for suggestions on what may be causing this behavior.
CH_IRQ_HANDLER(DebugMon_Handler) {
CH_IRQ_PROLOGUE();
uint32_t input = (CoreDebug->DCRDR);
uint8_t operation = (input & 0xff);
int operand = (input >> 8);
uint32_t demcr = CoreDebug->DEMCR
if ((demcr & CoreDebug_DEMCR_MON_REQ_Msk)) {
switch (operation) {
cases ...
default:
(CoreDebug->DEMCR) = demcr & ~CoreDebug_DEMCR_MON_REQ_Msk;
break;
}
}
CH_IRQ_EPILOGUE();
}
Solved! Go to Solution.
2026-04-20 8:14 AM
Case is solved. Went back through the BOM and found the wrong part number for the reset capacitor -- 1uf vs 0.1uf. Waiting (a lot) longer after deasserting reset enabled my communication software to work as expected. An embarrassing and difficult error to diagnose.
2026-04-20 7:36 AM - edited 2026-04-20 9:32 AM
Hi @Geoffrey1
Can you halt the CPU using CubeProgrammer?
To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.
2026-04-20 8:14 AM
Case is solved. Went back through the BOM and found the wrong part number for the reset capacitor -- 1uf vs 0.1uf. Waiting (a lot) longer after deasserting reset enabled my communication software to work as expected. An embarrassing and difficult error to diagnose.