E-paper and Teensy

[capeman121]

anyone can give me a hand with this please. thanks.

 

[KurtE]

Sorry, don't have the hardware...

Hard to know what your issues are. Might help if you posted the code you are actually trying to run, including links to any non standard (ones that don't ship with Teensy).

Also might help if you maybe showed some additional information, like maybe the summary data out of the compiler. For example how close are you to having all of RAM used?

Lots of possible things, could kill/hang program, so if it were me. I would hopefully have enough memory left to sprinkle in debug code...
Things like at the start of Setup, maybe print out that you got there...

Things like:

void setup() {
    while (!Serial && (millis() < 5000)) ;
    Serial.begin(115200);
    Serial.println("Setup called"); Serial.flush();
    (Call your first init function)
    Serial.println("First function completed"); Serial.flush();
...

Also I personally would use logic analyzer and setup unused digital pins, and do digitalWriteFast... calls around major things...
But my first step would be to see if a) Setup is actually called, and then see if I can localize farther down where things stop working...

@defragster does your debug code work on LC?

 

[defragster]

I did some early testing on T_LC and it worked - using the core 'weak' fault capture from PJRC code - and keep alive polling on USB. I saw the different behavior on memory boundaries Paul said to expect where I started testing. Nothing new should have broken that.

I'll power one up and test current samples and get an idea of the added RAM/FLASH requirements. I just have to find one here on my desk and get a few minutes … those things are too small ...

 

[defragster]

Found a T_LC. It doesn't have a cycle_counter which I was using to 'time' the 'panic' blink. Made a quick workaround that seems to suffice, though not always working with Auto (non-button) Reprogram as it was.

Tested on T_LC only - others should not be affected. There is one ODDITY {dumps string garbage} after a fault I'll need to look into - it seems okay to use as code already faulted. Not sure if it is unique to T_LC - or if I had another change in progress.

Here it is as tested in case it can help - see examples for usage after unzipping and placing into the 'sketchbook\libraries' folder:

View attachment debug_t3_LC.zip

Seems to add 3996 bytes of code and uses 132 bytes of RAM on T_LC Serial sketch compiled 'Smallest Code' using new example : "...\libraries\debug_t3\examples\DebugMin\DebugMin.ino"

With Debug included min T_LC Serial sketch:

Sketch uses 24736 bytes (38%) of program storage space. Maximum is 63488 bytes.
Global variables use 2600 bytes (31%) of dynamic memory, leaving 5592 bytes for local variables. Maximum is 8192 bytes.

Same code with all the debug library code and calls removed:

Sketch uses 20740 bytes (32%) of program storage space. Maximum is 63488 bytes.
Global variables use 2468 bytes (30%) of dynamic memory, leaving 5724 bytes for local variables. Maximum is 8192 bytes.

<edit>: Went back to T_3.6 with that code - the string garbage dump is somehow unique to T_LC - and going back to T_LC it doesn't show. The FAULT was in printf() so it was doing USB output. It was captured and helped - but the stream seems corrupted.

 

[capeman121]

Thanks so much @defragster ill take i look at it when i get back to the office on Monday. Ill post my results. When i tried i remembered it initializing fine but would stop when it started to draw anything. Ill give it another go with your files.

 

[defragster]

Hope you have code/ram room to add it and it can help. Just adding the header :: #include "debug_t3.h"
Will have it trap on faults if that is what you are running into.

And putting this in setup will make sure the USB is online first and attach a blink pin to flash when it faults:

void setup() {
  Serial.begin(115200);
  while (!Serial && millis() < 5000 );
  Serial.println("\n" __FILE__ " " __DATE__ " " __TIME__);
  DebState( LED_BUILTIN );

// ...

Then adding lines like this before suspect lines will indicate if that is where it was before it faulted:

  DebText2( "Hello World ", micros() ); // this 2 parameter print formats the string and the value and prints with record of the line number.
  DebText( "ping" ); // this will just print text "ping" and the line number where it happened.

_:L=25: Hello World 745088
_:L=28: ping

And from the example HardFaults - after commenting a couple early faults does this:

  uint8_t temp;
  deb_t3( 4, 222 );
  temp = UART2_C2;

Where deb_t3(4, 222) stored in element #4 ( valid are 0-9 ) the number 222 ( any uint32_t value ) - and records the function name since it was the last called before the fault. This code then forces a fault touching a serial port that was not initialized.

Resulting in this output showing the last line number it was told about and the function name that it was called from. The BOLD line tracks the last "deb_t3()" call where 222 is shown in DEC and HEX.

>>>> debug_fault >>>> debug_fault >>>> TYPE:hrd
Debug Info:
2 => 476 0x1DC [L#40_C#2
4 => 222 0xDE [L#51_C#6 _<< last func::setup
6 => 47825 0xBAD1 [L#42_C#3
7 => 1052688 0x101010 [L#47_C#5
8 => 476203 0x7442B [L#45_C#4

fault:
??: 4006C000 ??: 33 ??: 0
psr adr:FFFFFFF9
lr: 460E r12:C23 r3: 808080
r2: 1FFFFEDC r1: 1FFFFD40 r0: 460E
r4: 33 lr: 20
---

 

[capeman121]

Found a T_LC. It doesn't have a cycle_counter which I was using to 'time' the 'panic' blink. Made a quick workaround that seems to suffice, though not always working with Auto (non-button) Reprogram as it was.

Tested on T_LC only - others should not be affected. There is one ODDITY {dumps string garbage} after a fault I'll need to look into - it seems okay to use as code already faulted. Not sure if it is unique to T_LC - or if I had another change in progress.

Here it is as tested in case it can help - see examples for usage after unzipping and placing into the 'sketchbook\libraries' folder:

Seems to add 3996 bytes of code and uses 132 bytes of RAM on T_LC Serial sketch compiled 'Smallest Code' using new example : "...\libraries\debug_t3\examples\DebugMin\DebugMin.ino"

With Debug included min T_LC Serial sketch:


Same code with all the debug library code and calls removed:


<edit>: Went back to T_3.6 with that code - the string garbage dump is somehow unique to T_LC - and going back to T_LC it doesn't show. The FAULT was in printf() so it was doing USB output. It was captured and helped - but the stream seems corrupted.

Hey Defragster,

Were you able to get Ben's library and example to work on T_LC? Found HERE (google drive link under video)

I was unable to get it working. Once i upload it to the T_LC it is no longer shown on my pc as a device and the screen does nothing. I can press the button and re-upload the sketch or any other sketch but nothing else shows. Is this normal behavior you found? if not maybe im doing something wrong.

 

[defragster]

re: "Were you able to get Ben's library and example to work on T_LC? "

No, I hadn't looked to repro as I don't have the hardware - was hoping it might show help in your case.

 

[capeman121]

re: "Were you able to get Ben's library and example to work on T_LC? "

No, I hadn't looked to repro as I don't have the hardware - was hoping it might show help in your case.

yea i appreciate the debug code but i cant even get the teensy to work after uploading this sketch. seems to just crash. Was hoping to see if someone else had this working on an LC

 

[KurtE]

To second what Defragster said,

It is hard for us to help you, as we do not have the hardware.

Note: I (and probably several others) am somewhat lazy on helping out on some issues. Especially when there have been suggestions given, like maybe show the compiler summary info, to give an idea of how close you are to using up all RAM and we don't see any response from the suggestions.

Also maybe show us what program you are actually running? Again tend not to go through multiple links to get to a google drive and then try to figure out what parts are needed... Much easier if you maybe package it up in zip file... Note: it is fine for standard like libraries, from placed like Sparkfun, Adafruit... to simply say download the XYZ library from github or Arduino library manager...

If the program is blowing up in some hard fault, hopefully if you include the good work of Defragster it might give you an idea of what happened. Likewise if you add debug print outs around each major portion of code, then hopefully again allow you to isolate what is not working.

 

[defragster]

yea i appreciate the debug code but i cant even get the teensy to work after uploading this sketch. seems to just crash. Was hoping to see if someone else had this working on an LC

If the crash is from a hard fault - it just crashing is what is expected - and the value in the debug code was that it will ideally notify that indeed a crash has happened and perhaps provide some usable feedback as to where to look.

Following post #31 should show some USB output or at least a flashing LED in that case. Feedback on that is needed to have any understanding of what is happening that we can't see. And KurtE notes some prior questions that essential as well.