MicroMod Beta Testing

Need Help to port program from Teensy 4.1 to MicroMod

Hi, I'm trying to port Speeduino software (is designed to compile for ATmega2560, Teensy 3.5, Teensy 4.1, STM32) if I compile stock software have some errors about analog pins (MicroMod only have A0 to A13 and stock software use to A17)
I made some changes and I was able to compile, but when I upload to MicroMod board, it's crashing avery few seconds and connection reboots, What change need other than the pins asigment over Teensy 4.1 to work on MicroMod.
There is some other difference between 4.1 and MicroMod besides the pinout differences.
I attach the original and modified speeduino software if some one can check.
Thanks
 

Attachments

  • speeduino_Stock.zip
    1.6 MB · Views: 42
  • speeduino_MicroMod.zip
    1.6 MB · Views: 39
@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.
 
@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.
 

Attachments

  • speeduino-202305_MicroMod.zip
    1.6 MB · Views: 53
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?
 
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?

Here the CrashReport()
After upload code the first star don't show any problem
Code:
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)

Code:
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

Code:
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

Code:
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

It seems to reboot every 11/12 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.
 
Thanks, I change pins 2 to 5 for 42 to 45 but I have the same behavior T_MM reboot about every 13 seconds.

...

Just to note: That example code was how those pins were changed {P2-P5} in the sketch at hand - if that was somehow placed directly in the problem code it wouldn't have any affect.

Perhaps that was understood as intended - to search the code for similar pin issues.

CrashReport() indeed showing explains the reboot behavior - that was not observed in the referenced case - so perhaps the issues is unrelated.

The ELF file location is shown here in the build console window. Finding the actual addr2line was a bit harder on Windows - odd prefix to name and location. Old version from some other install on path used to work - but the included version with Teensy tool install was needed in recent use.
 
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.

Any tutorial on how to use addr2line?
 
@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.
 
addr2line is not hard to use... For some faults like addressing through nullptr it will tell you the command line parameters.

But with some versions of the IDE (actually the build system) it was not giving me good results.

So instead I often go to the same directory of the build and open the list file (<sketch name>.lst) in the build directory mentioned.
Can find looking at the build commands. I often find it by open a file explorer window. Type in the address: %temp%/arduino/sketches
look for the newest directory and then find the .lst file. Open it up in your favorite editor and look for the address mentioned.
 
@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?
 
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?

Probably the path I use won't help much: "C:\Users\kurte\bin\addr2line.exe" :D as I made a copy of it with the short name ...

It is one of the compiler tools... And the name often prefixed by the compiler name: For example on my machine the copy I have for the current beta on 2.1.x version
"C:\Users\kurte\AppData\Local\Arduino15\packages\teensy\tools\teensy-compile\11.3.1-beta2\arm\bin\arm-none-eabi-addr2line.exe"
 
Yeah, unfortunately on Windows using addr2line might be really painful. On LINUX it's no problem at all because recent versions of GCC support multi-arch out of the box so the system addr2line works perfectly fine with ARM binaries. So, I just plain type "addr2line -e SomeFirmware.elf 0x1234" on the command line and it works. You probably do want to copy the relevant addr2line version like KurtE did so that you don't have to go finding it. Or, use the LST file. Either way, it really helps if you can go to the relevant place it crashed and look at what the code was doing at the time.
 
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.

The easiest way to find the elf file is do a build. Bring Teensyloader to front and click on menu File/Open Hex File. A window will open showing its location. Then cancel the window.
 
Just doing new Windows machine and this is the "path" that gets to arm-none-eabi-addr2line.exe ... For IDE 2

%AppData%\..\Local\Arduino15\packages\teensy\tools\teensy-compile\11.3.1\arm\bin

Had another copy on path from another tool that worked before until recent tools change and had to find this current one.

The underlined part will expand to current user ...

When a fault occurs at a known address the CrashReport gives a note like this on usage:
Code:
  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]
 
Last edited:
Actually the file (Addr2line.exe) is stored in this directory:

C:\\Program Files (x86)\\Arduino\\hardware\\teensy/../tools/arm/bin/

which resolves to:

C:\Program Files (x86)\Arduino\hardware\tools\arm\bin

It was the bum steer that it was in the C:\Users\myDir\Local\Arduino15\packages\teensy\t.... that was causing me problems.
 
It depends on are you trying to find it for installs of IDE 1.8.x with Teensyduino installed or for Arduino 2.x:

For T1.8.x it is like you mentioned, except it also depends on where you installed the Arduino IDE. In my case for 1.8.19 I have it in:
Code:
"C:\arduino-1.8.19\hardware\tools\arm\bin\arm-none-eabi-addr2line.exe"

For T2.x (currently 2.1.1): With current Beta Teensydino. I am running 0.59.2
Code:
"C:\Users\kurte\AppData\Local\Arduino15\packages\teensy\tools\teensy-compile\11.3.1\arm\bin\arm-none-eabi-addr2line.exe"
The 11-3.1 part above will be different depending on which version of Teensy board package you have installed.

And with all things like this, probably the easiest way to find out where things are on your machine is by turning on verbose builds. Then look at the commands that are executed during your build.
Like:
Code:
"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.
 
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.

As I mentioned, sometimes especially with the new compiler, I have had better luck opening the list file.
 
Back
Top