Closed fabricedesre closed 7 years ago
There seems to be a std::panic::set_hook which would be a good addition.
This works well when ./flash.sh-ing, but we get stuck when just ./run.sh-ing
I added the following to board.c and it causes the reset function to issue a breakpoint and drop into the debugger rather than doing the reset.
typedef struct
{
volatile uint32_t DHCSR; /*!< Offset: 0x000 (R/W) Debug Halting Control and Status Register */
volatile uint32_t DCRSR; /*!< Offset: 0x004 ( /W) Debug Core Register Selector Register */
volatile uint32_t DCRDR; /*!< Offset: 0x008 (R/W) Debug Core Register Data Register */
volatile uint32_t DEMCR; /*!< Offset: 0x00C (R/W) Debug Exception and Monitor Control Register */
} CoreDebug_Type;
#define CoreDebug_BASE (0xE000EDF0UL) /*!< Core Debug Base Address */
#define CoreDebug ((CoreDebug_Type *) CoreDebug_BASE) /*!< Core Debug configuration struct */
int is_debugger_running(void) {
return (CoreDebug->DHCSR & 1) != 0; // Bit 0 is DEBUGEN
}
void reset(void)
{
if (is_debugger_running()) {
__asm volatile ("bkpt #0");
}
PRCMMCUReset(1);
}
The reset is actually working under the debugger, but because its doing a processor reset, its the same thing as pressing the reset button which will run the image from flash.
That prints: Panic at example/blinky.rs:42 : assertion failed:
(left == right)
(left:1
, right:2
) when hitting assert_eq!(1, 2)r? @dhylands
Will fix https://github.com/mozilla-sensorweb/sensorweb-firmware/issues/8