Teensyduino 1.55 Beta #1

Status
Not open for further replies.
Code:
if (size & 0xffff) size += 0x10000;
size = size & 0xFFFF0000;
Maybe this?

Just gave it a try and looks like its working. Thank you.

EDIT: Now when you put in 968 blocks you see that LFS doesn't retain the files - it re-initializes the drive
 
Now, the always erased area Paul mentioned needs to be taken into account?

if ( program_size <= 0xFFFFF) {program_size = 0x100000 ... }

But that would mean a probably smaller useable area. That's just a decision.
 
It's always 64k aligned.. :)

Yes, that was my original intention because the flash is erased in 64K blocks. At the time I adding that code in LittleFS.cpp, I had not yet worked on the 1.07 bootloader, so keeping the filesystem aligned to the granularity of block erase seemed prudent.

Whether we still need 64K align, I'm not sure. It does sacrifice some space. But it does guarantee the filesystem can't start in the middle of a 64K block which might need to be erased as your code size grows into using even the first byte.

In other words, I'm undecided so far whether we still need 64K block align. Just wanted to explain the original rationale and mention bootloader 1.07 erases (beyond 512K or 1M) in 64K increments.
 
Last edited:
Looks good, or probably could just be something like:
Code:
size = (size + 0xFFFF) & 0xFFFF0000;

Yep that works as well so will use that one. As Frank says it saves a jump.

Now, the always erased area Paul mentioned needs to be taken into account?
The only way I can think of to take that into account is to check if the T4 encryption is active but that assumes you want it to persist across uploads.
 
if ( program_size <= 0xFFFFF) {program_size = 0x100000 ... }

But that would mean a probably smaller useable area. That's just a decision.

LittleFS sorely needs documentation and better examples. My feeling is comments in the examples and documentation about usable size are probably the place to mention this.

We could restrict the size so people can't create filesystems which allocate any of the always-erased area. But I can imaging a lot of people would be unhappy with that limitation. For applications where the firmware is seldom or never updated, and the code size is relatively small, they very well may want to have a larger filesystem which comes with the caveat of being lost during a (seldom or never) code update.
 
Alcon
Just put in a PR for the changes to LittleFS Flash that we discussed for size as well as to delete the extra 4k on flashlen that Paul mentioned: https://github.com/PaulStoffregen/LittleFS/pull/23. May not want to incorporate just yet until everyone is finished testing - maybe for b2? Just wanted to do it before I forgot. Get distracted to easily.
 
A very minimal hello-world like example which works without additional chips. Open, read, write, erase, list directory - Commented. Or probably an example for each? As simple as possible.
I took a look at simple_dumpfile. Here it would be good to mention other options than SPI NOR (in a comment)
Code:
LittleFS_SPINAND  myfs;   //Specifies to use an SPI NOR Flash attached to SPI
 
If a sketch and/or library wishes to know if they are running secured. What is the best way to know? Likewise is there way to know if the chip is only able run ehex files?

Sorry again I may have missed this.

But would you look at the IOMUXC_GPR_GPR11 to see if encryption is running?
Or at 18...

Thanks
 
A very minimal hello-world like example which works without additional chips. Open, read, write, erase, list directory - Commented. Or probably an example for each? As simple as possible.
I took a look at simple_dumpfile. Here it would be good to mention other options than SPI NOR (in a comment)
Code:
LittleFS_SPINAND  myfs;   //Specifies to use an SPI NOR Flash attached to SPI

Could use a lot of defines but that gets confusing. Think I would rather use one example with notes like uncomment this line for xxx memory options. Could then also include what @KurtE just asked about knowing if encryption is running when you do flash - that probably should be its own example since encryption affects it with the memory area.
 
Speaking of LittleFS and examples and the like.

At some point would be great if we experimented as an option of adding creation and modification dates (probably also in FS.h) ... Obviously different feature than encryption, but...
 
Speaking of LittleFS and examples and the like.

At some point would be great if we experimented as an option of adding creation and modification dates (probably also in FS.h) ... Obviously different feature than encryption, but...

Would be nice as it will tie into updates for MTP and the like.
 
DMM showing this for current idling running the posted SINK sketch:

#1 - Production T4_1.05 - bare board :: 98mA-99mA : 48 °C
#2 - Unfused T4_1.07 in T4 PJRC Beta breakout :: 109 mA (powering breakout LED and other on the board?) : 59 °C
#3 - Fused T4_1.07 with key.pem - bare board :: 99 mA-100 mA : 55 °C

Not sure why #'s 1 and 3 can be so close and the temp read so diff is 1 mA that much extra heat?
Next step would be external measure - but that is more arbitrary ...

Ok last thing with temperature. I took a brand new T4 (by new I mean right out of the package) with no pins and ran the temp test. I am now seeing temps getting up to 59-60degC on the bare board. Wonder if the pins are acting as a heat sink for the board keeping the temp lower.
Capture.PNG
 
Ok last thing with temperature. I took a brand new T4 (by new I mean right out of the package) with no pins and ran the temp test. I am now seeing temps getting up to 59-60degC on the bare board. Wonder if the pins are acting as a heat sink for the board keeping the temp lower.
View attachment 25606

The #1 and #3 there as 'bare board' have no pins - indeed solder and pin mass would give more heat sink.

With the Brand new bare p#142 board showing 'same higher temp' - the one here running cool must be an anomaly? Looking close - it is BEFORE Paul started the PCB SILKSCREEN 'DOT_DASH' PCB maker markings - may FIRST RUN? But odd given it only uses 1 mA less current as measured here.

Unbagged a new Bare T_4.0 - looks like 28 mins running at 56 degrees:
Code:
28.0514, 56.32
28.0598, 55.70
 
Yep using the pre-LFS test sketch. Here is what I used for temp measurement on both boards

...

Could put it up on Github if you want.

Just put that PRE-LFS on : github.com/Defragster/T4LockBeta/tree/main/T4MemInfoKitchen

My bare NEW T4:
Code:
Verify secure code is running properly

Fail: Bus Encryption Engine is not active
Fail: Encryption region starts at wrong address
Fail: Program data is not within encrypted region
Fail: title_function() is not in encrypted region
Fail: title_text[] is not in encrypted region
Fail: csf is Zero

 6 Tests failed.  :-(0.0000, 55.09
0.0083, 55.09
0.0167, 55.09
...
4.9927, 56.32
5.0010, 56.32
5.0094, 55.70

And on T4_b ... not yet Locked:
Code:
Pass: Bus Encryption Engine is active
Pass: Encryption region starts at proper address
Pass: Program data is entirely within encrypted region
Pass: title_function() is within encrypted region
Pass: title_text[] is within encrypted region
Pass: csf not Zero

All Tests Passed.  :-)
0.0000, 58.94
0.0083, 58.94
...
4.9927, 59.65
5.0010, 59.65
5.0094, 60.35
5.0177, 60.35
 
Tim
Ran one more temp profile on the second T4 Beta Secure that has not been been locked or fuses set. Added it to the chart. Same max temp as the T4 bare production. Looks like pins and whether its in or out of a breakout or breadboard can reduce temp:
Capture.PNG
 
Backed up my pem.key and locked the one. All Good on >> Prod, UnLocked, and Locked.

Added this to local copy of isEncrypt:
Code:
  if ((HW_OCOTP_CFG5 & 0x04C00002) == 0x04C00002) {
    Serial.println("Secure mode set");
  } else {
    Serial.println("Secure mode NOT SET");
    ok--;
  }
On Locked Beta shows:
Code:
Verify secure code is running properly

Pass: Bus Encryption Engine is active
Pass: Encryption region starts at proper address
Pass: Program data is entirely within encrypted region
Pass: title_function() is within encrypted region
Pass: title_text[] is within encrypted region
Pass: csf not Zero
[B]Secure mode set[/B]

Tim
Ran one more temp profile on the second T4 Beta Secure that has not been been locked or fuses set. Added it to the chart. Same max temp as the T4 bare production. Looks like pins and whether its in or out of a breakout or breadboard can reduce temp:
View attachment 25610

Not sure why - but the original noted feel of hotter matches what I see here - though that feel is subjective for sure - mostly from touching more T_4.1 recently - real diff only 1-2 °F. Maybe just different runs of 1062's?

Using IR thermometer I see maybe half degree °C external where Locked (43.3) is hotter than Prod (42.6) ... both no pins. It is not made for close up use - but some inches - but used anyhow near MCU - and hottest spot seems same area on both.

Indeed any contact pulls heat - even the USB cable end is warm.
 
Just added TMM and T41. Think we are beating a dead horse now.
...

Indeed ... stone dead. Once I saw similar current that seemed to show indeed the horse being beaten was dead.

But your graphs are very nice! Where do they come from?
 
Status
Not open for further replies.
Back
Top