MicroMod Beta Testing

Saw this yesterday after LONG run of Pri(255) as above and all seems well except finger wiggle broke my finger mid screen :(
View attachment 24618

Took this image with phone - catching the display midline break - it was running happily but out of sync?

Couldn't post yesterday and my machine lost D: drive access? Had to restart - TyComm and Teensy or something was hanging any save or write access to D: ...
 
Last edited:
Sounds good. I found a T4 Audio board... I know I have several, but first one I found had female pins... Found new one with no pins, so will solder later.
Also will solder up pins to the ribbon breakout cable so can try different pins with it.

One thing I noticed with my DMA stuff sort of removed :( is that I don't believe we are doing any of the continuous updates mode like my 'V' command before. Where it was setup to receive an image and update the top half and bottom half depending on which part of the screen is being refreshed.

Wonder how it would work with the FlexIO stuff?

Had the same problem with the one audio board I had - so I ordered one from Amazon without headers (next day delivery) for testing that I soldered male headers on. Had lots of Rev C's with male headers :)

Only one way to find out about the FlexIO stuff :)
 
@defragster
Setting :: isrPrime_it.priority(146);
Seems to be fine. My supposition is that Flexio needs a priority bump - or it needs some detection/correction where it may get late interrupt service and then proceeding is using a bad pointer?

The Average/Default _isr priority is #128 - so using any other device could easily cause this conflict? Serial?/SPI?/i2
Think this one is above my pay grade so Kurt you want to give it a try :)

Tim - funny haven't seen any screen breaks yet. Even when the thread hung there was no faults - just hung the thread and zelda kept playing....
 
@defragster
Think this one is above my pay grade so Kurt you want to give it a try :)
I hear you, we are all at a pretty cheap pay grade :D

I am not sure which interrupt we are talking about? I don't believe we are using any flexIO interrupts.

There are two others that I know of:

First off we use an interrupt for detecting the VSYNC.
Code:
    while ((*_vsyncPort & _vsyncMask) != 0);
    attachInterrupt(VSYNC_PIN, &frameStartInterruptFlexIO, RISING);
    return true;
This is using the standard attachinterrupt code. So all of these interrupts funnel through one ISR
Code:
	attachInterruptVector(IRQ_GPIO6789, &irq_gpio6789);
	NVIC_ENABLE_IRQ(IRQ_GPIO6789);
So one could do: NVIC_SET_PRIORITY(IRQ_GPIO6789, 192); // 255 = lowest priority
Or some such thing to see if it helps.

OR: I experimented with finding out which pin/port this is, switch that pin back to normal mode PORTS1-5, and then use the appropriate ISR for the pin. I believe each of these ports have
2 IRQs one for lower 16 pins and another upper 16 pins... And you can setup direct so you have to scan...

Second: DMA... We have:
Code:
    dma_flexio.interruptAtCompletion();
    dma_flexio.attachInterrupt(dmaInterruptFlexIO);
And as such there is an interrupt. Been awhile since I looked how some of these work. There are IRQ numbers for these:
Code:
enum IRQ_NUMBER_t {
        IRQ_DMA_CH0 =           0,
        IRQ_DMA_CH1 =           1,
        IRQ_DMA_CH2 =           2,
        IRQ_DMA_CH3 =           3,
        IRQ_DMA_CH4 =           4,
        IRQ_DMA_CH5 =           5,
        IRQ_DMA_CH6 =           6,
        IRQ_DMA_CH7 =           7,
        IRQ_DMA_CH8 =           8,
        IRQ_DMA_CH9 =           9,
        IRQ_DMA_CH10 =          10,
        IRQ_DMA_CH11 =          11,
        IRQ_DMA_CH12 =          12,
        IRQ_DMA_CH13 =          13,
        IRQ_DMA_CH14 =          14,
        IRQ_DMA_CH15 =          15,
        IRQ_DMA_ERROR =         16,
...
I don't remember every doing enable on these, but probably built in somewhere.
But I think one can get the channel number as we do in an error condition: Serial.printf(" DMA channel #%u\n", dma_flexio.channel);
So then need to map this to the DMA IRQ (note these ISRS double up)
Code:
0 eDMA OR eDMA Channel 0 Transfer Complete
eDMA Channel 16 Transfer Complete
1 OR eDMA Channel 1 Transfer Complete
eDMA Channel 17 Transfer Complete
So simply mask to low nibble. and then one can probably set the priority of that one...

Now back to maybe nothing :D
 
Started a reboot sequence again? 't' and 'F' at Pri(144) ran 1 hr and 11 mins - no display - just the update print:
Code:
LP#=3013472	Pri#=117269	last Pri=107595547	ms=4270391	ipCyc%=61.22
new FlexIO data
...
new FlexIO data
HM01B0 Camera Test
HM01B0_FLEXIO_CUSTOM_LIKE_8_BIT
------------------
SENSOR DETECTED :-) MODEL HM01B0

No fault just a restart. On restart it sits at Prompt menu with nothing active? { nothing entered }

As of this entry it has spontaneously restarted 12 more times ( and counting ) after the above failure when it was running???

The 1062 chip on the T.MM is not warm to touch at all?
 
I hear you, we are all at a pretty cheap pay grade :D

I am not sure which interrupt we are talking about? I don't believe we are using any flexIO interrupts.

There are two others that I know of:

First off we use an interrupt for detecting the VSYNC.
Code:
    while ((*_vsyncPort & _vsyncMask) != 0);
    attachInterrupt(VSYNC_PIN, &frameStartInterruptFlexIO, RISING);
    return true;
This is using the standard attachinterrupt code. So all of these interrupts funnel through one ISR
Code:
	attachInterruptVector(IRQ_GPIO6789, &irq_gpio6789);
	NVIC_ENABLE_IRQ(IRQ_GPIO6789);
So one could do: NVIC_SET_PRIORITY(IRQ_GPIO6789, 192); // 255 = lowest priority
Or some such thing to see if it helps.

...

Right on point Kurt - just off by Half :)

HIGHER priority - number lowered to 102 - it was that SYNC interrupt that was getting missed. Using 192 was a fail.

Code:
void setupPR() {
  fillCache();
  Serial.println("\n" __FILE__ " " __DATE__ " " __TIME__);
  //isrPrime_it.priority(144);
  isrPrime_it.priority(128);
[B]  NVIC_SET_PRIORITY(IRQ_GPIO6789, 102);[/B]
}

This fixes the display to be stable and runs for some time so far.

Code:
redraw rate = 7.67 Hz
LP#=674797	Pri#=117258	last Pri=107595517	ms=211498	ipCyc%=61.18

4 minutes and counting ....
 
Remember the prior cont "F" was 'DMA'? It worked without issue with Pri(128) 't'.

Is that done diff than the FlexIO?

Still running well at 470 seconds and counting:
Code:
LP#=606426	Pri#=117259	last Pri=107595517	ms=411450	ipCyc%=61.18
redraw rate = 7.67 Hz
LP#=675032	Pri#=117260	last Pri=107595517	ms=412493	ipCyc%=61.19

<EDIT>: The MID SCREEN SPLIT is back sometime before 10 minutes - but still running. - like prior image

Image in p#676 a fail to show? - source was TOO large at 1.8MB
HMcam_breakS.jpg

<edit2>: Running an hour soon - only issue us split screen. So the GPIO interrupt has fixed the 't' busy _isr usage. Or at least hidden the problem when the _isr isn't handled "in time" - and when that happens the code faults.
 
Last edited:
Hi all
Disappeared for awhile so just catching up - nice fix.

I just added this to the init function after flexio_configure - this ok:
Code:
	flexio_configure();
	NVIC_SET_PRIORITY(IRQ_GPIO6789, 102);
	set_pixformat(PIXFORMAT_GRAYSCALE);    //Sparkfun camera only supports grayscale

EDIT:
Wanted to see if it made a difference with the original zelda but nope frame still hung.
 
Hopefully Pri(102) not problematic - it might trigger other things to interrupt as well? attachInterrupt() to some other sketch pin will also be elevated. Not sure about bus I/O pins that use interrupt triggers?

Just noticed TyComm has fallen silent and my display is not updating now - NO FAULT and NO AUTO RESTART - time in ms shows how long it ran - .987 hours - last look was at .959 hours when prior post was updated:
Code:
redraw rate = 7.67 Hz
LP#=626692	Pri#=117261	last Pri=107595517	ms=3553468	ipCyc%=61.19
LP#=642683	Pri#=117260	last Pri=107595517	ms=3554499	ipCyc%=61.19
LP#=675677	Pri#=117260	last Pri=107595517	ms=3555541	ipCyc%=61.19

Would be interesting if there was a discoverable reason the delayed Vsync GPIO interrupt causes trouble? The fault may be the obvious sign of the same issue that causes left and right half images to get frames out of sync, spontaneous restart, or just hanging? ... or may be not...

As noted the HMcam updates come through at 30 fps while the ili9341 updates only run at 15 fps.
 
Sorry taking it slow. What steps in Zelda to make it hang?

Of course I'm biased - but the 't' repro in ex_2 seems more straightforward. No Audio or TeensyThreads. Just normal operation where time response to the GPIO is delayed by other 'user sketch' activity.
 
@KurtE
Don’t be sorry, know what I felt like the days after. :)

Basically just us ‘F’ coninuous mode in the original Zelda. Not a problem sinc v2 works just by keep reading frames
 
Of course I'm biased - but the 't' repro in ex_2 seems more straightforward. No Audio or TeensyThreads. Just normal operation where time response to the GPIO is delayed by other 'user sketch' activity.

The issue with continuous only occurs in the Zelda sketch. Eample1 and 2 both work fine in continuous mode. Just curious what the issue is. Remember these are demo sketches. Probably should just put it back in the main loop and see if still a problem.
 
@KurtE
Don’t be sorry, know what I felt like the days after. :)

Basically just us ‘F’ coninuous mode in the original Zelda. Not a problem sinc v2 works just by keep reading frames

Thanks that is sort of what I assumed and was/am not updating...

I updated some priorities in the startread:
Code:
    while ((*_vsyncPort & _vsyncMask) != 0);
    NVIC_SET_PRIORITY(IRQ_GPIO6789, 102);
    NVIC_SET_PRIORITY(dma_flexio.channel & 0xf, 102);
    attachInterrupt(VSYNC_PIN, &frameStartInterruptFlexIO, RISING);

I changed the sketch camera thread:
Code:
bool hm01b0_flexio_callback(void *pfb)
{
  //Serial.println("Flexio callback");
  static uint8_t callback_count = 0;
  if (callback_count < 50) {
    Serial.print("#");
    callback_count++;
  }
  g_new_flexio_data = pfb;
  return true;
}

And it did print 50#s...
One image:
Code:
HM01B0 Camera Test
HM01B0_PJRC_CARRIER
------------------
SENSOR DETECTED :-) MODEL HM01B0
OSC_CLK_DIV: 0x29
ImageSize (w,h): 324, 244
Send the 'f' character to read a frame using FlexIO (changes hardware setup!)
Send the 'F' to start/stop continuous using FlexIO (changes hardware setup!)
Send the 'p' character to snapshot to PC on USB1
Send the 'b' character to save snapshot (BMP) to SD Card
Send the '1' character to blank the display
Send the 'z' character to send current screen BMP to SD
Send the 'V' character DMA to TFT async continueous  ...

HM01B0 Camera Test
HM01B0_PJRC_CARRIER
------------------
SENSOR DETECTED :-) MODEL HM01B0
OSC_CLK_DIV: 0x29
ImageSize (w,h): 324, 244
Send the 'f' character to read a frame using FlexIO (changes hardware setup!)
Send the 'F' to start/stop continuous using FlexIO (changes hardware setup!)
Send the 'p' character to snapshot to PC on USB1
Send the 'b' character to save snapshot (BMP) to SD Card
Send the '1' character to blank the display
Send the 'z' character to send current screen BMP to SD
Send the 'V' character DMA to TFT async continueous  ...

Reading frame
Finished reading frame
HM01B0 Camera Test
HM01B0_PJRC_CARRIER
------------------
SENSOR DETECTED :-) MODEL HM01B0
OSC_CLK_DIV: 0x29
ImageSize (w,h): 324, 244
Send the 'f' character to read a frame using FlexIO (changes hardware setup!)
Send the 'F' to start/stop continuous using FlexIO (changes hardware setup!)
Send the 'p' character to snapshot to PC on USB1
Send the 'b' character to save snapshot (BMP) to SD Card
Send the '1' character to blank the display
Send the 'z' character to send current screen BMP to SD
Send the 'V' character DMA to TFT async continueous  ...

HM01B0 Camera Test
HM01B0_PJRC_CARRIER
------------------
SENSOR DETECTED :-) MODEL HM01B0
OSC_CLK_DIV: 0x29
ImageSize (w,h): 324, 244
Send the 'f' character to read a frame using FlexIO (changes hardware setup!)
Send the 'F' to start/stop continuous using FlexIO (changes hardware setup!)
Send the 'p' character to snapshot to PC on USB1
Send the 'b' character to save snapshot (BMP) to SD Card
Send the '1' character to blank the display
Send the 'z' character to send current screen BMP to SD
Send the 'V' character DMA to TFT async continueous  ...

Reading frame
Finished reading frame
* continuous mode started
redraw rate = 0.08 Hz
HM01B0 Camera Test
HM01B0_PJRC_CARRIER
------------------
SENSOR DETECTED :-) MODEL HM01B0
OSC_CLK_DIV: 0x29
ImageSize (w,h): 324, 244
Send the 'f' character to read a frame using FlexIO (changes hardware setup!)
Send the 'F' to start/stop continuous using FlexIO (changes hardware setup!)
Send the 'p' character to snapshot to PC on USB1
Send the 'b' character to save snapshot (BMP) to SD Card
Send the '1' character to blank the display
Send the 'z' character to send current screen BMP to SD
Send the 'V' character DMA to TFT async continueous  ...

Reading frame
Finished reading frame
* continuous mode started
redraw rate = 0.05 Hz
HM01B0 Camera Test
HM01B0_PJRC_CARRIER
------------------
SENSOR DETECTED :-) MODEL HM01B0
OSC_CLK_DIV: 0x29
ImageSize (w,h): 324, 244
Send the 'f' character to read a frame using FlexIO (changes hardware setup!)
Send the 'F' to start/stop continuous using FlexIO (changes hardware setup!)
Send the 'p' character to snapshot to PC on USB1
Send the 'b' character to save snapshot (BMP) to SD Card
Send the '1' character to blank the display
Send the 'z' character to send current screen BMP to SD
Send the 'V' character DMA to TFT async continueous  ...

Reading frame
Finished reading frame
* continuous mode started
##redraw rate = 0.08 Hz
################################################

Next up: ILI9341_t3n in updateScreenAsync DMA interrupt at completion...

Then there still is an issue that I ran into with the DMA update, that is the continuous reading alternates between two buffers, when it completes a frame the callback code remembers the last one and then tries to update the display with it... However suppose before it actually does this, the camera completes the next frame and swaps back to the one we are writing the data out with... Part of that data may be overwritten. So in my other case I actually had 3 buffers. The two the camera alternates with and a 3rd one I am drawing from and then had code to say when I get a new frame, I remember it, and if the display is done with the previous one it swaps the one it last drew from with the one that the camera just gave it...

But first up see if TFT iSR priority fixes the current issue.
 
The issue with continuous only occurs in the Zelda sketch. Eample1 and 2 both work fine in continuous mode. Just curious what the issue is. Remember these are demo sketches. Probably should just put it back in the main loop and see if still a problem.

??:: The 't' in Ex_2 only/easily Faults with "F" continuous? When the prime _isr is Pri(128).

And noted - it Faults the same with no display updates : See p#674
 
Note: I now think it is the Teensy camera Thread that is getting starved...

Yep that makes sense. Tried changing time slices but no luck so as I mentioned I ditched the threads and put it into the main loop - probably not in the most efficient way and it of course worked. Redraw rate not terrific (3.39 vs normal 10 or so), But it works. Here it is if you want to give it a try - Uses your priority changes.
 

Attachments

  • Zelda-HM01B0.zip
    271.3 KB · Views: 46
??:: The 't' in Ex_2 only/easily Faults with "F" continuous? When the prime _isr is Pri(128).

And noted - it Faults the same with no display updates : See p#674

Thanks Tim. But as Kurt mentioned it was probably the thread getting starved so using example2 sketch to track it down probably would not have helped since it wasn't faulted just stuck.. My original thinking was to use the thread to improve performance but it backfired.
 
@All
Just updated Github for the priority fix as well as removing the use of TeensyThreads from the 1st Zelda example :) Thanks guys.
 
Ex_2 with SSD1306 loop box draw died after 35 minutes ... just stalled - no restart no Fault. ... Running "F" but not 't'.

Just called in loop() {loopPR()} and drawing boxes one inside the other { subset of AdaF testdrawrect() } each loop until done then clearScreen and repeat SSD1306 frozen mid draw - and according to the ili9341 image I was here when it died.

This is with the following - not sure if that impacts i2c? - but no 't' active:
Code:
  isrPrime_it.priority(128);
  NVIC_SET_PRIORITY(IRQ_GPIO6789, 102);

Lunch over ...

Turned off the :: NVIC_SET_PRIORITY(IRQ_GPIO6789, 102);
> It did in 90 seconds with "F" and the ssd1306 boxes that run from start, no 't'.
Teensy went offline crashed needed button to upload.

Started over adding second count to redraw rate ... as of now hitting 400+ secs on repro and not stopped again.

I did have my USB port ignoring Teensy again ... moved to Hub ... and now back okay ... but maybe the device going funky it messes up the port ... but no messages seen from Windows about that.

<edit> at:
Code:
redraw rate = 14.51 Hz	 [COLOR="#FF0000"]secs = 572[/COLOR]
HM01B0 Camera Test
HM01B0_FLEXIO_CUSTOM_LIKE_8_BIT

It Did a Restart, then another Restart?
With no SSD1306 drawing

Pause where TyComm couldn't communicate - the Restart:
Code:
HM01B0 Camera Test
HM01B0_FLEXIO_CUSTOM_LIKE_8_BIT
------------------
error reading HM01B0, address
SENSOR NOT DETECTED! :-(

USB Unplug and replug and SSD1306 and "F" started back up- and running okay at secs = 102
 
Note: I edited my output for the #s to always output and do CR every 64 or so..
Code:
  static uint8_t callback_count = 0;
    Serial.print("#");
    callback_count++;
    if (!(callback_count & 0x3f)) Serial.println();
I also updated the code, that calls the draw for it to include:
Code:
    if (g_new_flexio_data) {
      //Serial.println("new FlexIO data");
      if (tft.asyncUpdateActive()) {
        Serial.print("!");
      } else {
        Serial.print("%");
        tft.setOrigin(-2, -2);
        tft.writeRect8BPP(0, 0, FRAME_WIDTH, FRAME_HEIGHT, (uint8_t *)g_new_flexio_data, mono_palette);
...
Here is a debug run:

Code:
* continuous mode started
###%####%####%####%####%####%########%redraw rate = 0.68 Hz
####%####%####%####%####%####%#######%##
##%####%####%####%####%####%########%####%####%####%####%####%####%#######%###
##%####%####%####%####%####%#######%####%####%####%####%####%####%########%redraw rate = 3.39 Hz
###
#%####%####%######%##%####%#######%####%#####%####%##########%########%####%#
#%###%##%##%###########%########%####%####%####%###########%#######%####%###
#%##%###%###########%#######%#redraw rate = 2.97 Hz
###%####%####%###########%#######%####%#####%#
###%##########%########%####%###%##%#%###%###########%####%####%####%####%###
#%####%###%##%####%########%####%####%####%####%##%##%####%########%redraw rate = 3.31 Hz
####%####%##
##%###########%#######%####%####%####%###########%########%####%####%####%#
###%##%##%#####%#######%####%####%####%####%##%###%####%#######%####%####%####%#
##########%########%redraw rate = 3.05 Hz
####%####%####%###########%#######%####%####%####%####
##%##%####%########%####%####%####%######%##%####%#######%#####%##%##%###%##%###
########%#######%####%####%####%###########%########%redraw rate = 3.05 Hz
So we are reading in about 4 frames per each one we output.

Will play soon with 'V' mode that runs the Screen in Continuous update mode, and have it update...
May try about 3 different ways:
a) Just do the writeRect as part of the callback from Camera DMA... Probably get some tearing
b) Setup hook for Frame complete, and do it there... Again may get some tear...
c) Do the full with the half frame code I did earlier...
 
Didn't try Zelda update.

Got the PRI updates in the HM0180.cpp ...

Ex_2 now running with "F" and 't'. Each loop() is doing box draw or clear on the ssd1306, and also in loop() jumper on Serial5 to itself it cycling a string sent out in setup() at 1Mbaud, and printing a '.' on '\n' received:
Code:
........LP#=7	Pri#=117269	last Pri=107595547	ms=1016855	ipCyc%=61.23
.......redraw rate = 7.52 Hz	 secs = 1017
..LP#=8	Pri#=117258	last Pri=107595517	ms=1017923	ipCyc%=61.23
........LP#=7	Pri#=117254	last Pri=107595517	ms=1018840	ipCyc%=61.24
.........LP#=8	Pri#=117268	last Pri=107595517	ms=1019908	ipCyc%=61.23

... ILI9341 updates are precise and good ... there is an occasional out of sync half frame, but only one draw then it goes back to good full frame.

coming up on 20 minutes and looking good.

... of course as I typed that it stopped dead:
Code:
.........LP#=8	Pri#=117260	last Pri=107595517	ms=1086911	ipCyc%=61.24
........LP#=7	Pri#=117269	last Pri=107595547	ms=1087854	ipCyc%=61.23
....redraw rate = 7.52 Hz	 secs = 1088
.....LP#=8	Pri#=117260	last Pri=107595517	ms=1088897	ipCyc%=61.24
........LP#=7	Pri#=117254	last Pri=107595517	ms=1089839	ipCyc%=61.23
....

Maybe 30 seconds later it restarted ??? No Faults indicated?

SSD1306 running ...

Then is Restarted again before I could give commands while typing?

This time I did give commands : 't' and 'F' and it is running at 263 seconds and counting ...

1062 has no warmth - Any chance TempMon or something is acting up?
 
So we are reading in about 4 frames per each one we output.

Will play soon with 'V' mode that runs the Screen in Continuous update mode, and have it update...
May try about 3 different ways:
a) Just do the writeRect as part of the callback from Camera DMA... Probably get some tearing
b) Setup hook for Frame complete, and do it there... Again may get some tear...
c) Do the full with the half frame code I did earlier...
Think I may know why reading 4 frames for every one actually output.

The sensor by default is in Streaming mode and then we issue 1 frame before the actual read. Not sure this is the problem but a possibility. There is a standby mode but haven't figure out how to do that yet. Maybe its time :)

Are you still using Zelda (threaded or unthreaded)?
 
Note: I edited my output for the #s to always output and do CR every 64 or so..
...
So we are reading in about 4 frames per each one we output.

Will play soon with 'V' mode that runs the Screen in Continuous update mode, and have it update...
May try about 3 different ways:
a) Just do the writeRect as part of the callback from Camera DMA... Probably get some tearing
b) Setup hook for Frame complete, and do it there... Again may get some tear...
c) Do the full with the half frame code I did earlier...

When I disable screen output the 15 fps doubles to 30 fps - reported by the callback? Opps this was 30: hm01b0.set_framerate(60);

Disabled the ssd1306 and Serial5 calls as well as the tft.update.

It went ODD ??? Including ignoring the 'Program Button' ????

Repowered and getting this - and with 't' with reduced 'Prime _isr rates' - but it did this before without 't'?
Code:
LP#=7830448	Pri#=1001	last Pri=67537	ms=129463	ipCyc%=0.06
redraw rate = 61.38 Hz	 secs = 130
LP#=7830642	Pri#=1001	last Pri=67537	ms=130464	ipCyc%=0.06
LP#=7830692	Pri#=1001	last Pri=67537	ms=131465	ipCyc%=0.06
LP#=7830442	Pri#=1001	last Pri=67537	ms=132466	ipCyc%=0.06

Program Button been dead some 30 seconds - ignored and no light on T.MM? TFT backlight still lit so it has USB power?

Almost like the 1062 was turned off?

OKAY? It was OFF??? I tapped the ON/OFF button on PJRC.BB and it woke up to setup() menu text ????
 
Back
Top