MicroMod Beta Testing

Morning all,

Will play a little more with the 'V' stuff this morning. Note: I have not fully implemented the c) option yet to hopefully smooth some things out. Here are some issues I suspect with the two previous quick to do options:

a) update the frame buffer when the camera completes a frame: The code starts to update the tft frame when the update code could be anywhere within the TFT frame. So while doing the updates part of new frame, part of old frame, plus as frame buffer up in DMA memory, cache issues so only when I complete the update do I do an arm_dcache_flush which will force the new data from cache into real memory where DMA is working from. But before then some will make it through some won't ...

b) update when the display finishes a frame: The display continues to run from start of the buffer again, while we start to update the frame buffer. So have some bleed through issues and partial data of multiple frames like a). But in addition, we are working off the last buffer the camera gave us. But it can easily happen that while we are doing the writeRect8BPP, that the camera finished the next frame, and switched back tot he buffer we are working from. So again could get the start of new data...

So now for c) It is to update the screen at end of each half frame. I will have 3 buffers for now. The one I claim to do writeRects from. Such that both come from same buffer, and two that the camera walks back and forth on... And code to tell the camera to swap one buffer for another... This is what I had setup earlier in the DMA GPIO code.
 
Morning all,

Will play a little more with the 'V' stuff this morning. Note: I have not fully implemented the c) option yet to hopefully smooth some things out. Here are some issues I suspect with the two previous quick to do options:

a) update the frame buffer when the camera completes a frame: The code starts to update the tft frame when the update code could be anywhere within the TFT frame. So while doing the updates part of new frame, part of old frame, plus as frame buffer up in DMA memory, cache issues so only when I complete the update do I do an arm_dcache_flush which will force the new data from cache into real memory where DMA is working from. But before then some will make it through some won't ...

b) update when the display finishes a frame: The display continues to run from start of the buffer again, while we start to update the frame buffer. So have some bleed through issues and partial data of multiple frames like a). But in addition, we are working off the last buffer the camera gave us. But it can easily happen that while we are doing the writeRect8BPP, that the camera finished the next frame, and switched back tot he buffer we are working from. So again could get the start of new data...

So now for c) It is to update the screen at end of each half frame. I will have 3 buffers for now. The one I claim to do writeRects from. Such that both come from same buffer, and two that the camera walks back and forth on... And code to tell the camera to swap one buffer for another... This is what I had setup earlier in the DMA GPIO code.

Morning again

I did notice when I was walking through the DMA code that you were swapping buffers - now I know why :). Remember when you say we got rid of all your DMA GPIO stuff - well looks like more of its going back in :)

Anyway it did get a lot better especially if you have what looks like interrupts happening very fast. Actually took a break this morning and was looking of tensorflow lite :) Luckily some of leg work for the T4.x has already been done in another thread - now to brush it off :)

EDIT: If you remember this thread TensorflowLite for Teensy two eamples were provided. Hello_world (fade LED) and Micro_speech. Well just loaded the hello_world sketch on the TMM (on ML board) and it worked! Going to try micro-speech as soon as I solder on a microphone and see what happens. If it works I can clean it up and we can use it as another example. Did see an example floating around that uses a Arducam OV2640_2mp_mini which I happen to have one that I might try out at some point.
 
Last edited:
I just pushed up a new branch video_mode_partc with the do it at the sub-frames. You might give it a try or I could just do PR?

Right now it is in PJRC carrier 4 bit and I am in a system dead mode. It stopped running, holding program button for 20-30 seconds did not do anything... Time before I saw this, I just let it sit for 30 minutes or more and came back...
 
I just pushed up a new branch video_mode_partc with the do it at the sub-frames. You might give it a try or I could just do PR?

Right now it is in PJRC carrier 4 bit and I am in a system dead mode. It stopped running, holding program button for 20-30 seconds did not do anything... Time before I saw this, I just let it sit for 30 minutes or more and came back...

I'll give it a try. If it locks up will let you know Hope all is well :)
 
It was running again.

I am debugging if I stop Continuous and then try to do a single frame it gets part of frame, I do it a couple more times, and it dies...

I hear a pop sound and a reboot. Not sure if that pop is coming from headphone? It then does not want to restart... Or it may play a few notes and then die or none at all and at that point have not done anything with camera code...
 
I just pushed up a new branch video_mode_partc with the do it at the sub-frames. You might give it a try or I could just do PR?

Right now it is in PJRC carrier 4 bit and I am in a system dead mode. It stopped running, holding program button for 20-30 seconds did not do anything... Time before I saw this, I just let it sit for 30 minutes or more and came back...

Ok reporting back. Worked for a while and looked pretty good - only broke up if my finger wiggle was right on top of the camera. Did notice that after 'F' and "V' doing a tft.fillscreen no longer worked. sound finished so I cycled power.

That's when the problems started:
1. Locked up like it did yours, tried 15s restore but didn't work so for the heck of it I hit the on/off button and it came back to life so maybe it got into a power off state.
2. When restarted and even after a fresh reload started to restart on me after I did a 'V' so probably hardfaulting somewhere.

EDIT: what you said in your last post.
 
I am letting it cool off again... Wondering about power management for this carrier board?

That is I believe the Sparkfun breakout boards have a 1 amp 3.3v regulator. I think this breakout board has a .5amp regulator.

What I am unsure of on these boards, is this 3.3v regulator being used by the IMXRT chip or is there another on board regulator?

And then how much 3.3v current are we using, between:
Teensy, Audio, TFT, and camera?

Right now trying to debug the V on and Off and killing other modes... SO I have the Audio board unplugged.
 
I just pushed up a new branch video_mode_partc with the do it at the sub-frames. You might give it a try or I could just do PR?

Right now it is in PJRC carrier 4 bit and I am in a system dead mode. It stopped running, holding program button for 20-30 seconds did not do anything... Time before I saw this, I just let it sit for 30 minutes or more and came back...

will say again Kurt - the Video mode looks awesome :cool:

One thing I saw on the T.MM Blue 13==LED, during VID I'm not seeing BLUE, unless the 't' is on. Not sure that is a bad thing - just interesting the uninterrupted SPI SCK transfer doesn't let the LED emit.

A shame it takes 3 buffers. Don't suppose it would work to have Flexio repeat on 'one current' buffer until notified to leave that 'one' constant, and on "swap command" do next update toggle to the 'Other'? Using just 2 buffers in turn.

Or even more 'dreamy' - since the 4/8 bit VID camera read is faster (60 fps?) than 1 bit SPI display write (30 fps or less?): "command B" the Flexio to do a NULL update to 'nowhere buffer B' { maybe a 2nd tiny buffer where each scan line goes to the same buffer? } leaving a single FULL 'buffer A' untouched after current Flexio update, and continue that until "command A" is given to return to updating the single full 'buffer A', and maybe Flexio do a Callback when back when the 'buffer A' and it is half full? Not sure if the Flexio could run well like that - and could have a race condition where after getting Half Full Callback when ready the sketch would issue "command B" say I'm ready to use the 'buffer, A' then a short wait overlap after "command A" for the next frame to start and get half done - but that could break video continuous smooth transfer from fixed buffer waiting for the 'half done Callback'
 
Sounds like you two are stressing the PJRC.BB VReg like I was seeing in past days? Leading to the T.MM getting faulty power and function on that breakout?
> and T.MM function was failing and doing restarts ... or going from ON to OFF
> I was seeing Button fail to initiate Bootloader as well as the 15s Restore. 15s Restore not needed as shown moving the T.MM to SFun.ML - but total fail on that was ugly.

>> As noted in the Ex_2 SerMon output - the temp is now hitting 57C (from prior 52C) during VID continuous display update - and it can't make that heat without extra mA's (and assume the display running faster is eating more mA's too?). Maybe time for testing a heat sink on the T.mm 1062?

Well ... my time for this visit over for a bit ... gotta run to town for a password for a computer I got yesterday.
 
RE image space for SD WRITE:

I noted this the other day and REMOVED it from Ex_2 :: That image array is "Unused Variable" after Mike's rewrite to 'always use the latest image in another buffer' IIRC.
>> That line can be removed from all other examples - now commented in git/KurtE "CameraThread.ino"

Code:
//DMAMEM unsigned char [B][COLOR="#FF0000"]image[/COLOR][/B][324*244];
void [B]send_image[/B]( Stream *imgSerial) {
  uint32_t imagesize;
  imagesize = (320 * 240 * 2);
 
I am letting it cool off again... Wondering about power management for this carrier board?

That is I believe the Sparkfun breakout boards have a 1 amp 3.3v regulator. I think this breakout board has a .5amp regulator.

What I am unsure of on these boards, is this 3.3v regulator being used by the IMXRT chip or is there another on board regulator?

And then how much 3.3v current are we using, between:
Teensy, Audio, TFT, and camera?

Right now trying to debug the V on and Off and killing other modes... SO I have the Audio board unplugged.

Interesting. Just did a little look on digikey. Wonder if this would be a replacement for the MCP125S33 on their now: https://www.digikey.com/en/products/detail/microchip-technology/MIC39100-3-3WS/771641 pretty sure I could replace it if it was?
 
Sounds like you two are stressing the PJRC.BB VReg like I was seeing in past days? Leading to the T.MM getting faulty power and function on that breakout?
> and T.MM function was failing and doing restarts ... or going from ON to OFF
> I was seeing Button fail to initiate Bootloader as well as the 15s Restore. 15s Restore not needed as shown moving the T.MM to SFun.ML - but total fail on that was ugly.

>> As noted in the Ex_2 SerMon output - the temp is now hitting 57C (from prior 52C) during VID continuous display update - and it can't make that heat without extra mA's (and assume the display running faster is eating more mA's too?). Maybe time for testing a heat sink on the T.mm 1062?

Well ... my time for this visit over for a bit ... gotta run to town for a password for a computer I got yesterday.

Tim - not really stressing. Until this latest update I never had an issue with the PJRC BB failing and doing restarts.... of going from ON to OFF nor having an issue with the 15s restore. Did notice in this last test seems not to work if the TMM goes to OFF state. If I hit the on/off button it started up without the need for a restore.
 
RE image space for SD WRITE:

I noted this the other day and REMOVED it from Ex_2 :: That image array is "Unused Variable" after Mike's rewrite to 'always use the latest image in another buffer' IIRC.
>> That line can be removed from all other examples - now commented in git/KurtE "CameraThread.ino"

Code:
//DMAMEM unsigned char [B][COLOR="#FF0000"]image[/COLOR][/B][324*244];
void [B]send_image[/B]( Stream *imgSerial) {
  uint32_t imagesize;
  imagesize = (320 * 240 * 2);

Sorry Tim - with everything else just plain forgot about that one. Just pushed an updated to the lib to get rid of the image buffer before I forgot again.
 
Wonder if this would be a replacement for the MCP125S33 on their now: https://www.digikey.com/en/products/detail/microchip-technology/MIC39100-3-3WS/771641 pretty sure I could replace it if it was?

You're talking about the voltage regulator on Sparkfun's ML carrier board, right?

Their schematic says the part number is AP7361C-33FGE. Here's the part at Digikey. https://www.digikey.com/en/products/detail/diodes-incorporated/AP7361C-33FGE-7/5638320

The datasheet says it can handle up to 1 amp.

The MCP1825S-3302E/DB part I used on the breakout board is rated for only 0.5 amp.

All linear regulators dissipate heat, so it could be a thermal problem. But their board looks like it has a large copper pour on the bottom side and 4 vias to conduct heat from the AP7361C's bottom side thermal pad to the bottom of the PCB. I did something similar on the breakout board with 16 vias to conduct the heat from the regulator's tab to the ground plane inside the PCB (the breakout board is 4 layers).

Thermal issues are pretty easy to check by just touching the part. It it's burning hot, then you know there's a problem.
 
You're talking about the voltage regulator on Sparkfun's ML carrier board, right?

...

No, on the PJRC.BB. I found noted troubles in past days keeping the T.MM working, today Kurt and Mike are seeing similar 'stumbles' ... see post 807 and 809 above.

Was just doing a current check on the PJRC.BB with T.MM:
Code:
Only seeing peak USB 5V current at 0.180 A with “V” – then peak dropped to 0.178
>	With fresh DMM battery It was 0.175 but has climbed with runtime.
>	Temp reporting 53C max with  some hits at 54C with ‘t’ off then on to view.

DMM on interrupted USB cable power line – back fresh and cool T.MM on PJRC.BB: T.MM on BB with HM_CAM, SSD1306 on i2c and included ILI9341 wired to PCB socket.

That current seems within range - unless something else is interfering with steady output.

T.MM will go into a state where Button does not take to Bootloader, or do a 15s Restore. And the T.MM will restart and go into OFF mode.
> Moving that T.MM to SFun.ML will work fine - so the T.MM isn't the problem ... see email and post of prior days for more details.
> Returning to PJRC.BB will work for some time ... then troublesome behavior recurs.
 
The other possible voltage regulator issue I can see is the output capacitor. All LDO type regulators need a certain range of capacitor for stability. LDOs aren't inherently stable like standard high-dropout regulators.

I see page 10 of the AP7361C datasheet says:

The output capacitor is required to stabilize and improve the transient response of the LDO. The AP7361C is stable with very small ceramic output capacitors. Using a ceramic capacitor value that is at least 2.2μF on the output ensures stability. Higher capacitance values help to improve line and load transient response. The output capacitance may be increased to keep low undershoot and overshoot. Output capacitor must be placed as close as possible to OUT and GND pins.

Looks like Sparkfun used only 1.32uF total capacitance.

screenshot.png

When designing with LDOs, it's usually pretty risky to be right at the minimum capacitance, since many of the capacitors on the market give less capacitance when used near their maximum voltage spec.

The MCP1825S regulator I used on the breakout board requires 1uF capacitance. I used a 4.7uF capacitor on the bottom side of the PCB.


So if the chip isn't burning hot, I'd suggest adding another capacitor to Sparkfun's board. If you can work with a microscope or good magnifier, you might be able to just solder another capacitor on top of one of the 3 Sparkfun already put on the PCB.
 
No, on the PJRC.BB. I found noted troubles in past days keeping the T.MM working, today Kurt and Mike are seeing similar 'stumbles'

Sounds like I need to get the test running here, maybe over the weekend. I've not managed to keep up with this thread over the last several days. Any chance I can talk you into giving me a quick recap on which hardware to connect and what code to run to reproduce the problem here?
 
Sounds like I need to get the test running here, maybe over the weekend. I've not managed to keep up with this thread over the last several days. Any chance I can talk you into giving me a quick recap on which hardware to connect and what code to run to reproduce the problem here?

Guess I am on line first now so just a quick summary from what I remember, sure @defragster will give you more.

Using the Example2 sketch in the main repository (https://github.com/mjs513/TMM-HB01B0-Camera) Tim was seeing the problems that he described with the 15s restore, restarts etc (see post 809). The only think on the PJRC BB was the TMM and ILI9341 and the SSD1306 attached to Wire. Think this is Tim's config.

Running the same sketch but if I remember most of the time I left the audio shield on the board I was seeing those issues with the Example2 sketch.

Today @KurtE and I were testing modifications he made to lib for the video mode in his fork (https://github.com/KurtE/TMM-HB01B0-Camera/tree/video_mode_partc) and saw the same issues when testing with the Zelad_HM01B0 sketch (not the v2 version). Then I started seeing issues with restarts and shutting down (my case I hit the on/off button and the TMM came back).

EDIT: Just read Tim's post below and forgot about instructions on using the sketches. That's Tim.

With the Zelda sketch the command usage is the same as @defragster stated except you should hear Zelda playing. Again just to be clear this only happened with Zelda using Kurt's repository. These have not yet been incorporated into the main repository. The Zelda sketch in the mjs513 repository works without hanging the last I checked for me.
 
Sounds like I need to get the test running here, maybe over the weekend. I've not managed to keep up with this thread over the last several days. Any chance I can talk you into giving me a quick recap on which hardware to connect and what code to run to reproduce the problem here?

Noted in p#815 : T.MM on PJRC.BB: T.MM on BB with HM_CAM, SSD1306 on i2c and included ILI9341 wired to PCB socket

I was crafting email and clipped that from there and deleted email. The Sketch here is :: ...\libraries\HM01B0\examples\HM01B0_example2\HM01B0_example2.ino
>> Confirm the following and Build sketch from current mjs513 github
> #define MMOD_ML 0 // for PJRC.BB
> #define TFT_ILI9341 1 // for this tft versus commented // TFT_ST7789
> #define _hmConfig 3 // or other except '0' for the PJRC.BB
>> Run Sketch
> Once SerMon connects and shows 'help', an attached WIRE i2c ( SFUN 0x3C ) SSD1306 should begin drawing boxes within boxes { clearing and restarting that process, driven by loop() update }.
> confirm 'f' gives a good image
> confirm 'F' gives a good image continuously
> do 'F' to stop continuous update
> Start "V" for video display to ili9341 and confirm a beautiful stable clean and smooth updating image appears
> (Optionally) perhaps start 't' that begins a background _isr and showing 1 sec updates on SerMon loading the MCU during any background camera and TFT updates
----> watch the TFT for camera output, and SSD1306 for box drawing ( Normal for update from loop() to slow during TFT screen VID updates ) those should continue as will 't' SerMon updates
--->> T.MM should remain stable and AUTO Programmable, and should respond to program Button when tried.

It started here 2-3 days ago - [ see email may be more details ] - T.MM was fine moving over to SFun.ML - Twice - return to PJRC.BB {some hours later} worked well at first then noted failures.
> then returning T.MM fresh to the PJRC.BB it works fine for some unmeasured hour(s) when the behavior repeats.

Given that it took Mike and Kurt 2-3 days to perhaps start to experience what was already happening here a true fault may not appear for some many hours. Since returning the T.MM to the PJRC.BB it may be near an hour since I began the current Current testing, and so far all is well.
--> Kurt and Mike were running some version of the Zelda sketch with an Audio Board - I never got that far as it takes a working PJRC.BB to set that up directly with 4 bit camera I/O, and mine was failing before I finished doing my 't' {Torment or Timing test}

The only Good/BAD thing is that it isn't just the PJRC.BB here, since the other two are showing similar issues.

I don't have an OScope - or even a quality meter (or probe setup) - but as noted when it was failing once a DMM on GND/3.3V { the teensy layout 3.3V IIRC } it was showing 3.3V then toward 2.5V at that time and cycling back up. When looking at other 3.3V on the edge pin sockets - at least one was not showing the same dips? Not sure if there are secondary caps inline anywhere that might allow diff voltages to appear on those different points?

Paul: On your end perhaps you can monitor POGO test pins and 3.3V presented at various points on PCB and perhaps the issue leading to the anomaly will be apparent before it gets to point of failure.

As noted: That T.MM once it shows failure moved to SFun.ML with similar hardware will power up and run the SSD1306 boxes - though Camera and TFT are not wired to work until the sketch is edited for that carrier.

<EDIT> :: UPDATE

Since going back to PJRC.BB to test Current draw from USB it has been maybe almost 2 hours? It has restarted a couple times with connection cut measuring the current, and reprogrammed once. Since last restart it was at "ms=20472622047262" or 34 minutes.

Saw the image below on TFT and turning meter back on to current it stopped updating and only drawing 0.094 A down from 0.178 A typical Max.

Pressing On/Off for some half second ( a second time ) the T.MM came back to life running the SSD1306 with SerMon online << This seems like the start of failure case at hand

On restarting (for now) the T.MM system is running well. At some point it may start spontaneous restarts (or shutting off) if like before - though at this point the Button still goes to Program.

CamOddonBB.jpg
Image is my hands holding camera in front of the TFT/Camera to take the picture - it was still running then until I turned the DMM back on, now running again the current is the same 0.178 A max.

<Add>: only other feature of 't' is looping Serial5 data when pins 20<>21 are crossed on PJRC.BB. Not likely relevant or critical to repro - but that explains the "S5#=0" field when not wired. When wired loop() subfunction reads .available() bytes and counts then retransmits them, like SSD1306 it was just a task the user might exercise bringing more MCU hardware into play.
 
Last edited:
@Paul
Forgot to mention something. At the beginning of each sketch there are four configurations you can setup:
Code:
#define _hmConfig 1 // select mode string below

PROGMEM const char hmConfig[][48] = {
 "HM01B0_SPARKFUN_ML_CARRIER",     //8bit camera
 "HM01B0_PJRC_CARRIER",    //4bit camera
 "HM01B0_FLEXIO_CUSTOM_LIKE_8_BIT",   //8bit camera where you can set the pins you want to use
 "HM01B0_FLEXIO_CUSTOM_LIKE_4_BIT"    //4bit camera where you can set the pins you want to use
};
All my testing on the PJRC BB has been with _hmconfig = 1 while @defragster I think has been testing with _hmconfig = 2 (8bit).
 
@Paul
Forgot to mention something. At the beginning of each sketch there are four configurations you can setup:
...
All my testing on the PJRC BB has been with _hmconfig = 1 while @defragster I think has been testing with _hmconfig = 2 (8bit).

Remembered to include that in p#819 - currently I have #3 - 4 bit selected - though, correct mostly before it was #2.

Since the odd image above - restart has been on "V" for another 2600 seconds to far without issue.

Since my normal test case would involve long runs with reprogram at times - I just uploaded to #2 :: HM01B0_FLEXIO_CUSTOM_LIKE_8_BIT

Temps are now again showing more toward 54C - warmer than prior on PJRCC.BB with newer faster VID updates - but still less than 57C shown on the SFun.ML carrier.

Repowered DMM showing high of 0.179 A, and with 't' temp tending some drops to to 53C as it slows but doesn't ruin the "V" video.

The only ODD current indication so far was the 0.094 that showed when the 1062 core was "OFF" - while the TFT and SSD were still powered by PJRC.BB.

>. Note: so far so good on the restart with :: #define _hmConfig 2
LP#=36 Pisr#=511169 lastPR=1022849 ms=881559 ipCyc%=43.47 S5#=0 54C

>> Update 143 minutes since change to HM config 2 update - and fine now:
LP#=35 Pisr#=510813 lastPR=1022141 ms=8608576 ipCyc%=43.73 S5#=0 53C

>> Did the colored vid image again like p#819 - but again still running - DMM timed out - not sure it it did it then, that's when I looked - kept running
LP#=35 Pisr#=510758 lastPR=1022033 ms=14867602 ipCyc%=43.69 S5#=0 54C
> Program ogain okay with alt _isr props: fewer longer _isr's
>> const int PrPS=1000 * 200; // pick number 30K to 120K, 220K or more net completed depends on priRestart val and tableSize
>> #define priRestart 107361011 // Larger Primes takes longer :: 521 // 65537 // 53680457 // 107361011 // 107375183 // 2147503639 // 2147712181
LP#=34 Pisr#=111416 lastPR=107583841 ms=176288 ipCyc%=59.18 S5#=0 53C

Interesting - Vid stopped with similar colorized image: "V" stopped - and f and F worked for good image? Then "V" restarted - but DMM beeped and turning it off restarted it ...
Code:
LP#=34	Pisr#=111391  lastPR=107583781  ms=2780313  ipCyc%=59.38  S5#=0  53C
* continuous mode stopped
LP#=34	Pisr#=113519  lastPR=107588027  ms=2781309  ipCyc%=59.69  S5#=0  53C
LP#=36	Pisr#=114130  lastPR=107589269  ms=2782325  ipCyc%=59.55  S5#=0  53C
LP#=35	Pisr#=114128  lastPR=107589263  ms=2783316  ipCyc%=59.54  S5#=0  53C
LP#=35	Pisr#=114130  lastPR=107589269  ms=2784308  ipCyc%=59.55  S5#=0  53C
Reading frame
Finished reading frame
* continuous mode started
redraw rate = 0.00 Hz	 secs = 2790		deg  C=53
[B]* continuous mode stopped[/B]
Before Set frame complete CB
Before UPdateScreen Async
[B]* continuous mode (Video) started[/B]
redraw rate = 0.01 Hz	 secs = 2880		deg  C=53

T.MM on PJRC.BB still acting usably correct - except image 'colorization' ...
 
Last edited:
Remembered to include that in p#819 - currently I have #3 - 4 bit selected - though, correct mostly before it was #2.

Since the odd image above - restart has been on "V" for another 2600 seconds to far without issue.

Since my normal test case would involve long runs with reprogram at times - I just uploaded to #2 :: HM01B0_FLEXIO_CUSTOM_LIKE_8_BIT

Temps are now again showing more toward 54C - warmer than prior on PJRCC.BB with newer faster VID updates - but still less than 57C shown on the SFun.ML carrier.

Repowered DMM showing high of 0.179 A, and with 't' temp tending some drops to to 53C as it slows but doesn't ruin the "V" video.

The only ODD current indication so far was the 0.094 that showed when the 1062 core was "OFF" - while the TFT and SSD were still powered by PJRC.BB.

Note: so far so good on the restart with :: #define _hmConfig 2
>> LP#=36 Pisr#=511169 lastPR=1022849 ms=881559 ipCyc%=43.47 S5#=0 54C

Out of curiosity I am running the default setup in example2 using the PJRC.BB and _hmconfig = 2. Should be the same as yours. Only about 10minutes in and all is working good so far - boxes updating nicely and nice ILI9341 display.

And I am seeing temps near 54C here as well but the ambient temp in the room is a bit higher tonight. Will update after its been running for awhile going to go and do something instead of staring at the screen :)

UPDATE: Ok about 34minutes in the test the SSD stop and the PJRC.BB restarted but it also coincided with my PC going to sleep so can't say 100% if it was the PC to BB connection that caused the restart when I woke the PC back up. Didn't expect that one :)

But up to that point was running fine. Have to figure something else out.

UPDATE: Froze after 30minutes but pressed restart/pgm and it started right up - no issue with the TMM just hung and can't restart. Didn't see any of this behaviour running in 4bit mode to be honest.

Need sleep so will test some more in the morning.
 
Last edited:
BreakoutBoard goes Wonkey again : power on 9-10 hours

It has been 9-10 hours of continuous runtime on PJRC.BB since the T.MM was put back on - with above noted 'Colorized' output display, and successful reprograms and running.

SEE POST #819 for repro steps with code below. When this behavior happened startup commands were : f, F, F, t, V { where the 't' give runtime/temp info as shown } - there was no Serial5 pin crossing, thus "S5#=0".

Follow up to p#821: For completeness here is the Example2.ino sketch as last uploaded - minor adjustments from git copy perhaps - ready to run on PJRC.BB in 8 bit custom mode:
Code:
[B][ATTACH]24672._xfImport[/ATTACH][/B]

Similar operation for days on end with SFun.ML board never showed these issues, now in this state - if like prior - the T.MM on this board will not present normal function at this time whether power cycled, reprogrammed or other, and would not likely complete a 15s Restore to Blink.
> But if moved to the SFun.ML - with only change of "#define MMOD_ML 1" for programming it would work fine, and as noted even without reprogramming the SSD1306 on Wire would enter loop and function showing Box cycles no problem with active SerMon.

It was running along - looked up and it was no longer running, it restarted and sat - with dead SSD showing 0.1 A on DMM ... Letting it SIT (some time longer than a few seconds?) it has just restarted again and again SSD is again dead after a short run ... not sitting as long it restarted again and the SSD ran some partial set of boxes - this time showing 0.162 A on DMM:
Code:
LP#=34	Pisr#=111497  lastPR=107584003  ms=4098972  ipCyc%=59.77  S5#=0  53C
LP#=35	Pisr#=111403  lastPR=107583793  ms=4099985  ipCyc%=60.20  S5#=0  53C
HM01B0 Camera Test
HM01B0_FLEXIO_CUSTOM_LIKE_8_BIT
------------------
SENSOR DETECTED :-) MODEL HM01B0
OSC_CLK_DIV: 0x2A
ImageSize (w,h): 324, 244
START Fill Cache :: 3221
END Fill Cache :: 	Last is 82813	 @ 3268

T:\tCode\libraries\HM01B0\examples\HM01B0_example2\HM01B0_example2.ino Apr 30 2021 23:45:40
Send the 'f' character to read a frame using FlexIO (changes hardware setup!)
[B][COLOR="#FF0000"] // HELP on RESTART[/COLOR][/B]
Send the 'z' character to send current screen BMP to SD

HM01B0 Camera Test
HM01B0_FLEXIO_CUSTOM_LIKE_8_BIT
------------------
SENSOR DETECTED :-) MODEL HM01B0
OSC_CLK_DIV: 0x2A
ImageSize (w,h): 324, 244
START Fill Cache :: 3221
END Fill Cache :: 	Last is 82813	 @ 3268

T:\tCode\libraries\HM01B0\examples\HM01B0_example2\HM01B0_example2.ino Apr 30 2021 23:45:40
Send the 'f' character to read a frame using FlexIO (changes hardware setup!)
[B][COLOR="#FF0000"] // HELP on RESTART[/COLOR][/B]
Send the 'z' character to send current screen BMP to SD

HM01B0 Camera Test
HM01B0_FLEXIO_CUSTOM_LIKE_8_BIT
------------------
SENSOR DETECTED :-) MODEL HM01B0
OSC_CLK_DIV: 0x2A
ImageSize (w,h): 324, 244
START Fill Cache :: 3221
END Fill Cache :: 	Last is 82813	 @ 3268

T:\tCode\libraries\HM01B0\examples\HM01B0_example2\HM01B0_example2.ino Apr 30 2021 23:45:40
Send the 'f' character to read a frame using FlexIO (changes hardware setup!)
[B][COLOR="#FF0000"] // HELP on RESTART[/COLOR][/B]
Send the 'z' character to send current screen BMP to SD

HM01B0 Camera Test
HM01B0_FLEXIO_CUSTOM_LIKE_8_BIT
------------------
error reading HM01B0, address
SENSOR NOT DETECTED! :-(

... DMM showing 0.162 A current usage - so the T.MM has not switched off, but for at least 10 minutes has sat idle after SSD1306 started box cycle, and stopped.

I just pressed 'Button' - it went to bootloader ... DMM showing 0.140

Unplugged USB cable with inline DMM to PJRC.BB, plugged in USB cable. It started normally with 'help' and some run of SSD Box cycle - then stopped with DMM showing 0.101 A for a couple of minutes ...

Press of On/Off brought it to life to 0.168 A and less than 2 SSD Box cycles - DMM went to 0.101 A, as I typed this line it SELF restarted, quickly stopped to OFF/0.1A, Restarted and RAN a few SSD Box cycles ... and it is now in a REPEAT of that 3? times already with no user intervention, on last restart there were a couple dozen SSD Box cycles ... then an EXIT to OFF 0.101 A ... and another self restart ...

Returning SSD1306 and T.MM to SFun.ML as expected it returns to SerMon and running the SSD Box Cycle - display and camera offline as they are not in programmed locations - but '?' and 't' show responsive SerMon.

While waiting I did restore FrankB's Print HardFault and tested on a T_4.1, but this code was built and tested with FRESH cores from a couple days back. The nature of this behavior would be hanging with that CORES code - so a Fault is not apparent. It appears electrical in nature.

NOTES back on SFun.ML:
Using $1 SFun : Raspberry Pi Micro USB to USB-C Adapter the SFun.ML w/T.MM - not yet reprogrammed for ML=1 - SSD1306 Box cycles running and tft backlight on at 0.174 A and 't' showing 53C and mostly 54C with video not running.
Reprogramming the T.MM to run on the ML carrier : Up and running 6 minutes so far with no problem - will leave it on during Zzzz's.
> Properly programmed for ML before issuing commands the T.MM is drawing 0.193 A peak
> { f,F,F,t,V } is showing 01.97A { 0.200 Amps with SD card plugged in - which was removed as no SD was on the PJRC.BB }
-> the ML board does have two 'inactive' MEMS mics and a ULP Accelerometer on board, and Red and Orange status LEDS for extra current draw?
 
Last edited:
Morning all,

I thought I would do a little testing on the ML board, to avoid the maybe power issue...

But the interesting thing on this board with it's camera I do not get a good FlexIO image... It is like there is not valid sync... I know from earlier I was getting lots of random VSYNC pulses...
Which is why earlier in the GPIO/DMA code, I checked that the Pulse was > threshold in time and then would trigger the DMA code and that was the last time I looked at VSYNC..

SO this morning I decided to instrument the current stuff to see when the VSYNC ISR is begin hit, plus, when the DMA ISR is being hit, plus when the DMA Callback is being run and when the TFT call back is being run.

Note: I am using a modified version of example1... Needed to #ifdef out the SDCard function and buffer to allow the frame buffer to be created.

Sample Run:
screenshot.jpg
Top row - Vsync ISR, Next - FlexIO DMA isr, Camera Frame CB, TFT Screen Frame complete CB...

Wonder if I should put in different Camera and see if it responds different.
 
Morning all,

I thought I would do a little testing on the ML board, to avoid the maybe power issue...

But the interesting thing on this board with it's camera I do not get a good FlexIO image... It is like there is not valid sync... I know from earlier I was getting lots of random VSYNC pulses...
Which is why earlier in the GPIO/DMA code, I checked that the Pulse was > threshold in time and then would trigger the DMA code and that was the last time I looked at VSYNC..

SO this morning I decided to instrument the current stuff to see when the VSYNC ISR is begin hit, plus, when the DMA ISR is being hit, plus when the DMA Callback is being run and when the TFT call back is being run.

Note: I am using a modified version of example1... Needed to #ifdef out the SDCard function and buffer to allow the frame buffer to be created.

Sample Run:
View attachment 24676
Top row - Vsync ISR, Next - FlexIO DMA isr, Camera Frame CB, TFT Screen Frame complete CB...

Wonder if I should put in different Camera and see if it responds different.

@KurtE = Morning to you as well

Interesting results - saw double pulse on the vsync while sometime it was single - pardon my ignorance but it that normal.

As for trying it with a different camera its a possibility. There were some comments on the Spartfun forum where 1 camera would not work with their lib but then they replaced it with new one and it worked. So one way to find out :)
 
Back
Top