New firmware release v1.17.2.b1 (Flash encryption support)

[robert-hh]

@daniel Done, added.

[livius]

@xykon
but if i do not need to encrypt flash?

[daniel]

@livius said in New firmware release v1.17.2.b1 (Flash encryption support):

Question - what do wdt on boot? I suppose it can be turned on/off?
But how to access to the object instance then?
We must create wdt object self and feed it or it is created on boot time with some timeout?
Maybe i misunderstood this..

https://docs.pycom.io/chapter/firmwareapi/pycom/pycom.html#pycomwdtonboottimeouttimeout

Just use the WDT as usual when your app starts.

[livius]

@daniel

Just use the WDT as usual

Now its clear :) and docs are refreshed :)

It is not possible to use secure boot without flash encryption.

but if i do not need to encrypt flash?

[Xykon]

@livius said in New firmware release v1.17.2.b1 (Flash encryption support):

@xykon
but if i do not need to encrypt flash?

Flash encryption and secure boot are optional features.

If you want to use secure boot then you also have to use flash encryption.

[livius]

@xykon
Then if i do not specify SECURE=on it is not defaulted to on? as you say it is optional.

ach!! i ommit ":" it is not about default on only what is default after turned on ;-)

if SECURE=on by default:
encryption is enabled
secure_boot_signing_key.pem is the secure boot key, located relatively to Makefile
flash_encryption_key.bin is the flash encryption key, located relatively to Makefile

i go to sleep and rest ;-)

[daniel]

@robert-hh thanks. I can reproduce it. We will analyse and resolve ASAP.

[robert-hh]

@daniel It crashes not all the time with a crash log. Similar often it simply stalls and cannot even be interrupted with Ctrl-C.

[robert-hh]

@daniel Changing the script into the below makes it stable. Just sleep_ms(1) added to the loop:

import utime
from machine import Pin

pin = Pin("P10", Pin.OUT)
pin(0)

diff = const(2500000-1000)

while(True):
    start = utime.ticks_us()
    pin(1)
    while utime.ticks_diff(start, utime.ticks_us()) < diff:
        utime.sleep_ms(1)
    start = utime.ticks_us()
    pin(0)
    while utime.ticks_diff(start, utime.ticks_us()) < diff:
        utime.sleep_ms(1)

[robert-hh]

@daniel Similar problems on a simple reboot with Ctrl-D. Just tried it a few times. Empty main.py, empty boot.py.

MicroPython 1bf377b on 2018-03-16; FiPy with ESP32
Type "help()" for more information.
>>> 
PYB: soft reboot

network config: ('10.0.0.149', '255.255.255.0', '10.0.0.240', '10.0.0.240')
Guru Meditation Error: Core  1 panic'ed (StoreProhibited)
. Exception was unhandled.
Register dump:
PC      : 0x4008c239  PS      : 0x00060133  A0      : 0x8008b9be  A1      : 0x3ffe3040  
A2      : 0x00fe4dc8  A3      : 0x00060120  A4      : 0x00000001  A5      : 0x0000abab  
A6      : 0xb33fffff  A7      : 0x3ffc2d3c  A8      : 0x0000cdcd  A9      : 0x3ffe3040  
A10     : 0x0000abab  A11     : 0x00060123  A12     : 0x00060120  A13     : 0x3ffb4fa0  
A14     : 0x00000003  A15     : 0x00060023  SAR     : 0x00000018  EXCCAUSE: 0x0000001d  
EXCVADDR: 0x00fe4dc8  LBEG    : 0x4009b2ac  LEND    : 0x4009b2b7  LCOUNT  : 0x00000000  

Backtrace: 0x4008c239:0x3ffe3040 0x4008b9bb:0x3ffe3070 0x40102cb3:0x3ffe30b0

================= CORE DUMP START =================
zDoAABEAAABsAQAA
dHf9P3Bf/T8gYf0/
cF/9P8Bg/T9XcQAAGFL8PxhS/D90d/0/EFL8PwcAAACQw/0/kMP9P3R3/T8AAAAA
EgAAACRT/T90aVQAdAClJkZyBeD8qegA////fyBh/T8AAAAAIQAGABIAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAke/0/jHv9P/R7/T8AAAAAAAAAAAEAAAAAAAAA
01lAPwAAAACouAlAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAINehw==

[daniel]

@robert-hh yeap, I'm seeing that as well....

[robert-hh]

This post is deleted!

[robert-hh]

@daniel I reverted back to 1.17.0b1. It looks like the soft reset problem already existed there.
Update: No soft reset problem in version 1.16.0.b1

[ssmith]

@Xykon You said awhile back that you were working on a release program for FW releases and possibly Beta testing before releasing FW. How close are you to implementing this? I'm having a real hard time accepting the fact that PyCom keeps releasing new FW with very little testing. I have seen issues in almost every FW release that just a minimal QA test should discover. If PyCom's target customers are hobbyists, you have a great product. If PyCom wants to sell products to companies that are trying to base a business off using these devices then something needs to change ASAP. This kind of behavior from PyCom will put many start-ups relying on PyCom out of business.

[timh]

@ssmith I would agree with your assessment.

I am endeavoring to use GPY & FiPY to monitor a number of devices in a commercial setting (between 50 and 150 high value devices) which implies that many pycom boards.

The package, functionality (LTE, sigfox, gps) etc.. all go together to make it an ideal platform.

However not being able to get LTE to work, finding a way to repeatably hang device in latest firmware doesn't instill a great deal of confidence.

I have a little bit of time up my sleeve however if I have no traction resolving LTE in the next few weeks, then I must look to another solution.