hugovw1976
Member
Some one test the current draw on rtc?
Or it's the same from teensy 4.1/4.0
Or it's the same from teensy 4.1/4.0
ifdef ARDUINO_TEENSY_MICROMOD
#define P2 42
#define P3 43
#define P4 44
#define P5 45
#else
#define P2 2
#define P3 3
#define P4 4
#define P5 5
#endif
Thanks, I change pins 2 to 5 for 42 to 45 but I have the same behavior T_MM reboot about every 13 seconds.@hugovw1976: As was found with Analog pins - some digital pins have alternate numbering as well and some pins cause trouble.
Working a simple sketch the other day on T_4.1 then moved to T_MM and had the MicroMod going offline until I changed the pins in use on the ATP carrier. Never got to the bottom of it - just moved the pins as follows for Pins P2 to P5 when built for T_MM:
Code:ifdef ARDUINO_TEENSY_MICROMOD #define P2 42 #define P3 43 #define P4 44 #define P5 45 #else #define P2 2 #define P3 3 #define P4 4 #define P5 5 #endif
Pins 2,3,4,5 are valid on T_MM - but somehow using them was not good, taking it offline after upload - so moving them to Pins 42,43,44,45 worked.
Thanks, I change pins 2 to 5 for 42 to 45 but I have the same behavior T_MM reboot about every 13 seconds.
By the way just in case in previous post the modified Speeduino code is the same as the stock, I upload in this post the correct one.
With resolution here CrashReport() wasn't used - but it might point to some trouble. Restart wasn't seen here - but the fault restart delay is 8 seconds and that may indicate ~5 seconds in this case?
No Crash Data To Report
Hopefully all is well, but certain types of crashes can't be reported:
stuck in an infinite loop (technically, hardware still running properly)
remaining in a low power sleep mode
access to certain peripherals without their clock enabled (eg, FlexIO)
change of CPU or bus clock speed without use of glitchless mux
Breadcrumb #1 was 2691136810 (0xA0677D2A)
Breadcrumb #2 was 1980305870 (0x760911CE)
Breadcrumb #4 was 3399558836 (0xCAA126B4)
Breadcrumb #6 was 2021791097 (0x78821579)
CrashReport:
A problem occurred at (system time) 15:3:49
Code was executing from address 0x9C1E
CFSR: 82
(DACCVIOL) Data Access Violation
(MMARVALID) Accessed Address: 0x206D656C
Temperature inside the chip was 47.72 °C
Startup CPU clock speed is 600MHz
Reboot was caused by auto reboot after fault or bad interrupt detected
CrashReport:
A problem occurred at (system time) 15:4:0
Code was executing from address 0x9C1E
CFSR: 82
(DACCVIOL) Data Access Violation
(MMARVALID) Accessed Address: 0x206D656C
Temperature inside the chip was 48.95 °C
Startup CPU clock speed is 600MHz
Reboot was caused by auto reboot after fault or bad interrupt detected
CrashReport:
A problem occurred at (system time) 15:4:12
Code was executing from address 0x9C1E
CFSR: 82
(DACCVIOL) Data Access Violation
(MMARVALID) Accessed Address: 0x206D656C
Temperature inside the chip was 50.18 °C
Startup CPU clock speed is 600MHz
Reboot was caused by auto reboot after fault or bad interrupt detected
Thanks, I change pins 2 to 5 for 42 to 45 but I have the same behavior T_MM reboot about every 13 seconds.
...
Use addr2line with the resulting ELF file from the compile and the address (0x9C1E) to get where it is crashing. I tried this myself. I don't have a micromod in suitable conditions to directly test but I compiled the sketch you attached above and then used addr2line on it. It says the crash is happening at scheduledIO.ino:80 which is endCoil2Charge.
Now, I may be using a different version of Teensyduino than you (1.57.2) so this may not be accurate. But, the idea holds. You can do it yourself but you'd need to find where it is storing the resulting ELF file. On linux for me this is in /tmp/arduino_build_916297 where the end numbers change every time I restart the IDE. Go in there, use addr2line -e speeduino.ino.elf 0x9C1E
EDIT: I should probably mention that the ELF is a temporary file that goes away every time you close the IDE so you have to compile and then go looking for it. Don't close the IDE until you're well and truly done.
Hi, Can you tell me where the addr2line.exe file is. I have searched through drive C (includes sub folders) and C:\Users\Me\AppData\Local and it's sub directories but cannot find it. I find all sorts of mention of it but not the actual program. Where did it originate from, Arduino or Teensduino or something else?@hugovw1976 - IIRC the line shown by crashreport - though not shown above, indicates the syntax for the cmdline to display the affected area of the code based on the indicated address seen at the time of the crash.
The build console will have a display of the needed .elf file path. The needed addr2line.exe is installed in the tools directory - though took a search to locate in the "%appdata%\..\local" path on Windows, not sure of the OS in use there.
Hi, Can you tell me where the addr2line.exe file is. I have searched through drive C (includes sub folders) and C:\Users\Me\AppData\Local and it's sub directories but cannot find it. I find all sorts of mention of it but not the actual program. Where did it originate from, Arduino or Teensduino or something else?
The easiest way in 2.1 or 1.8 is to do a build. Select all the contents of the output window and copy paste into a text editor and search for 'arm-none-eabi-gcc'. Copy the directory that that is in into a terminal window, go there and list. You will see 'arm-none-eabi-addr2line' there. Make an alias.Hi, Can you tell me where the addr2line.exe file is. I have searched through drive C (includes sub folders) and C:\Users\Me\AppData\Local and it's sub directories but cannot find it. I find all sorts of mention of it but not the actual program. Where did it originate from, Arduino or Teensduino or something else?
Code was executing from address 0xFFFFFFFE
CFSR: 83
(IACCVIOL) Instruction Access Violation
(MMARVALID) Accessed Address: 0x0 (nullptr)
Check code at 0xFFFFFFFE - very likely a bug!
[B]Run "addr2line -e mysketch.ino.elf 0xFFFFFFFE" for filename & line number.[/B]
"C:\arduino-1.8.19\hardware\tools\arm\bin\arm-none-eabi-addr2line.exe"
"C:\Users\kurte\AppData\Local\Arduino15\packages\teensy\tools\teensy-compile\11.3.1\arm\bin\arm-none-eabi-addr2line.exe"
"C:\\Users\\kurte\\AppData\\Local\\Arduino15\\packages\\teensy\\tools\\teensy-compile\\11.3.1/arm/bin/arm-none-eabi-gcc-ar" rcs ...
Use addr2line with the resulting ELF file from the compile and the address (0x9C1E) to get where it is crashing. I tried this myself. I don't have a micromod in suitable conditions to directly test but I compiled the sketch you attached above and then used addr2line on it. It says the crash is happening at scheduledIO.ino:80 which is endCoil2Charge.
Now, I may be using a different version of Teensyduino than you (1.57.2) so this may not be accurate. But, the idea holds. You can do it yourself but you'd need to find where it is storing the resulting ELF file. On linux for me this is in /tmp/arduino_build_916297 where the end numbers change every time I restart the IDE. Go in there, use addr2line -e speeduino.ino.elf 0x9C1E
EDIT: I should probably mention that the ELF is a temporary file that goes away every time you close the IDE so you have to compile and then go looking for it. Don't close the IDE until you're well and truly done.
Finally have some time to check addr2line and it's the same scheduledIO.ino:80, It's no make much sense, I change pin assigment but it's the same problem, I need more time to go deeper and fine a solucion.
Thanks.