//test 4.1 for reboot h/w vs s/w
WDT_T4<WDT1> wdt;
WDT_timings_t config;
void setup() {
// WATCHDOG
config.timeout = 5;
wdt.begin(config);
while(!Serial.begin(115200)&& millis()<3000);
if(!wdt.expired()){ //restart was not the result of watchdog timeout
//must have been a power off/on or software reboot
//force a wdt timeout here then next restart will be true
//inc counter & save to eeprom
delay(6000);
}
//continue with setup
}
void loop() {
wdt.feed();
} uint32_t SRSR = SRC_SRSR;
if (SRSR & SRC_SRSR_LOCKUP_SYSRESETREQ) {
// use SRC_GPR5 to distinguish cases. See pages 1290 & 1294 in ref manual
uint32_t gpr5 = SRC_GPR5;
if (gpr5 == 0x0BAD00F1) {
p.println(" Reboot was caused by auto reboot after fault or bad interrupt detected");
} else {
p.println(" Reboot was caused by software write to SCB_AIRCR or CPU lockup");
}
}
if (SRSR & SRC_SRSR_CSU_RESET_B) {
p.println(" Reboot was caused by security monitor");
}
if (SRSR & SRC_SRSR_IPP_USER_RESET_B) {
// This case probably can't occur on Teensy 4.x
// because the bootloader chip monitors 3.3V power
// and manages DCDC_PSWITCH and RESET, causing the
// power on event to appear as a normal reset.
p.println(" Reboot was caused by power on/off button");
}
if (SRSR & SRC_SRSR_WDOG_RST_B) {
p.println(" Reboot was caused by watchdog 1 or 2");
}
if (SRSR & SRC_SRSR_JTAG_RST_B) {
p.println(" Reboot was caused by JTAG boundary scan");
}
if (SRSR & SRC_SRSR_JTAG_SW_RST) {
p.println(" Reboot was caused by JTAG debug");
}
if (SRSR & SRC_SRSR_WDOG3_RST_B) {
p.println(" Reboot was caused by watchdog 3");
}
if (SRSR & SRC_SRSR_TEMPSENSE_RST_B) {
p.println(" Reboot was caused by temperature sensor");
SRC_SRSR &= ~0x100u; /* Write 0 to clear. */
p.println("Panic Temp Exceeded Shutting Down");
p.println("Can be caused by Overclocking w/o Heatsink or other unknown reason");
IOMUXC_GPR_GPR16 = 0x00000007;
SNVS_LPCR |= SNVS_LPCR_TOP; //Switch off now
asm volatile ("dsb":::"memory");
while (1) asm ("wfi");
}if (SRSR & SRC_SRSR_IPP_USER_RESET_B) {
// This case probably can't occur on Teensy 4.x
// because the bootloader chip monitors 3.3V power
// and manages DCDC_PSWITCH and RESET, causing the
// power on event to appear as a normal reset.
p.println(" Reboot was caused by power on/off button");
}setup() function something like this (which will wait for a maximum of 3 seconds for the serial monitor to be connected, then proceed): while (!Serial && millis() < 3000) {}.setup() function, right after the while (!Serial && millis() < 3000) {} line, which will print out any crash information:if (CrashReport) {
Serial.print(CrashReport);
}Thanks for the tips. I eventually found the CrashReport link and saved it. I will check out the addr2line utility as well.
#pragma once
#include <Printable.h>
#include <WString.h>
class CrashReportClass: public Printable {
public:
virtual size_t printTo(Print& p) const;
void clear();
operator bool();
void breadcrumb(unsigned int num, unsigned int value) {
// crashreport_breadcrumbs_struct occupies exactly 1 cache row
volatile struct crashreport_breadcrumbs_struct *bc =
(struct crashreport_breadcrumbs_struct *)0x2027FFC0;
if (num >= 1 && num <= 6) {
num--;
bc->value[num] = value;
bc->bitmask |= (1 << num);
arm_dcache_flush((void *)bc, sizeof(struct crashreport_breadcrumbs_struct));
}
}
};
extern CrashReportClass CrashReport;
Thanks for the insight. Hadn't appreciated the differing value settings to a single bread crumb. That's helpful.
CrashReport.breadcrumb(2, 6);
// this section runs the state machine... button presses cause us to change states
doStateMachine();
CrashReport.breadcrumb(2, 7);
/* The following code requires a hardware modification of the ELS board to work. If the
mod is not made, there will be no Serial print output! As this is diagnostic only, it
only matters for logging stepper rpm and ztogo. It does not affect operation.
You must connect physical pin 7 (logical 5 IN2) PUL to physical pin 25 (33 MCLK2) at the
end of part next to the SD card
*/
if (freq1.available()) {
sum1 = sum1 + freq1.read();
count1 += 1;
}
//Serial.printf("freq1.available() = %i\n", freq1.available());
CrashReport.breadcrumb(2, 8);
if (pulsetimeout > 250) {
if ((count1 > 0) && stepperactive) {
step_pps = freq1.countToFrequency(sum1 / count1);
updaterate = step_pps * 25.4f/(12.0f * 800.0f) * 1000.0f; // approx display call rate!
// NB: @ 400 RPM, 0.2mm feed, about 1333 counts/sec
#if defined(USB_TRIPLE_SERIAL)
SerialUSB2.printf("%3.10lf, %3.3f, %3.3f\n", mysec(), step_pps, ztogo); // keep step_pps to preserve datalog.
#endif
}
sum1 = 0; count1 = 0; pulsetimeout = 0;
}
// end code requiring PCB modification
CrashReport.breadcrumb(2, 9);
blub = mysec(); // dummy call, ensures mysec is properly updated. Only needs an update once every 7 sec.
#ifdef forceerror
CrashReport.breadcrumb(2, 10);
if (errortimer > 20000) { // force a CrashReport after 20 seconds since start, but since we reset we get whacked every 20 seconds
volatile byte *p = nullptr; /* using this pointer will crash */
*p = 5;
}
#endif
}CrashReport:
A problem occurred at (system time) 15:42:38
Code was executing from address 0x67FE
CFSR: 82
(DACCVIOL) Data Access Violation
(MMARVALID) Accessed Address: 0x0 (nullptr)
Check code at 0x67FE - very likely a bug!
Run "addr2line -e mysketch.ino.elf 0x67FE" for filename & line number.
Temperature inside the chip was 48.13 °C
Startup CPU clock speed is 600MHz
Reboot was caused by auto reboot after fault or bad interrupt detected
Breadcrumb #2 was 10 (0xA)
(0x8950973D)
Breadcrumb #2 was 10 (0xA)
Breadcrumb #3 was 17580490 (0x10C41CA)
Breadcrumb #6 was 3794188452 (0xE226B8A4)CrashReport.breadcrumb(2, 1) to CrashReport.breadcrumb(2, 10)
Yes, good luck Find the addr2line installed with teensyduino package.
[arm/bin] $ ./arm-none-eabi-addr2line -e ~/Library/Caches/arduino/sketches/C798958FCBDCA6AB7A9C28AB1D2FD52A/teensy-electronic-lead-screw.ino.elf 0x2179E
??:?
[arm/bin] $
The sym file is unsorted, kind of hard to make sense of it. I found the instruction in the lst file, which is readable, but I don't know where in the code (whose library) it is happening.
[arm/bin] $ ./arm-none-eabi-objdump -C -d -l -S ~/Library/Caches/arduino/sketches/C798958FCBDCA6AB7A9C28AB1D2FD52A/teensy-electronic-lead-screw.ino.elf > ~/Documents/mydump.txtI generally drop it into a spreadsheet, ensuring the address columns are set to text (mayhem ensues otherwise), then filter and sort as needed. It’s not easy, though
Yes, definitely avoid serial output from within an ISR. Even
sprintf could be problematic, as I think it uses the heap. There are various ring buffer utilities around designed to be used to transfer information from ISR to your foreground code. I’ve not used any myself, but someone will be along with a recommendation shortly, I expect.Having the serial output, did prove to me the ISR was working as designed, at least at lower data rates. But pushing 4MB through the interface at high speeds did prove to be an undoing. I've tried not to put in printf statements in ISR's, for good practice, but I really needed to know if my crazy idea was working.I generally drop it into a spreadsheet, ensuring the address columns are set to text (mayhem ensues otherwise), then filter and sort as needed. It’s not easy, though
Yes, definitely avoid serial output from within an ISR. Evensprintfcould be problematic, as I think it uses the heap. There are various ring buffer utilities around designed to be used to transfer information from ISR to your foreground code. I’ve not used any myself, but someone will be along with a recommendation shortly, I expect.
With my current build, there are no serial outputs in an ISR except for a serious fault condition, (missing a count) which has never occurred in 18 months. So now, there are no serial outputs in an ISR under normal operation. All my serial printing is in the foreground code. Missing a count is serious, as now there's an ever increasing error, which is why I allow that to be communicated. The Teensy has never missed a count, such a message has never been output.