New firmware release v1.17.0.b1 (Completely new LTE class)
-
@IOAg @danielm just an update I got my FiPy working on Telstra with your latest firmware. Details posted here: https://forum.pycom.io/topic/2769/telstra-lte-cat-m-working-on-fipy-just
-
Just updated Gpy to new firmware but as soon as i call the LTE class it crashes. Any idea why?
import os
os.uname()
(sysname='GPy', nodename='GPy', release='1.17.0.b1', version='v1.8.6-849-d0dc708 on 2018-02-27', machine='GPy with ESP32')
from network import LTE
lte=LTE()
/Users/danicampora/Code/Espressif/IDF/esp-idf-20180112/components/freertos/./queue.c:718 (xQueueGenericSend)- assert failed!
abort() was called at PC 0x40089fb8 on core 1 -
@daniel
Is there possibility to store variables in rtc memory from python code?
This memory survive deep sleep.
This is already avaiable byRTC_DATA_ATTRto declare variable stored in RTC memory. -
@livius yes, this is part of the roadmap. Expect it in a few weeks.
-
@liviue I can not find this RTC_DATA_ATTR in documentation. Can you post an example?
-
@colateral said in New firmware release v1.17.0.b1 (Completely new LTE class):
RTC_DATA_ATTR
only from source code and custom firmware
not available in python
you can find details here:
https://github.com/pycom/pycom-esp-idf/blob/master/components/esp32/include/esp_attr.h -
@livius ahhh.. thanks :)
-
In a previous post I pointed out a simple fix to the Pycom firmware updater to correctly set the serial baud rate to what YOU PYCOM set it to when you ship the module.
With this new updater it's compiled so I can't change it, and the bug is still there.
Why don't you listen?
-
@colinza said in New firmware release v1.17.0.b1 (Completely new LTE class):
In a previous post I pointed out a simple fix to the Pycom firmware updater to correctly set the serial baud rate to what YOU PYCOM set it to when you ship the module.
With this new updater it's compiled so I can't change it, and the bug is still there.
Why don't you listen?
The firmware updater always connects with an initial baud rate of 115200bps (and this does not depend on the firmware as the esp32 is running the ROM bootloader) and then instructs the esp32 to switch to the baudrate as chosen in the GUI firmware updater: 921600bps when high-speed transfer is selected (which is the default) and otherwise 57600 bps.
It would be extremely odd if your USB / TTL adapter works at 115200 bps but not at 57600 bps (maybe you can provide some more details about your OS and the adapter so I can check if I can replicate this?)
I've actually been planning to increase the "slow" baud rate from 57600 to 115200 as pretty much all computers these days should be able to handle the upload at 115200 bps. You should see a beta announcement for a new firmware updater in the next few days.
-
@xykon I'm using a pretty standard Atmega 8u2 based adaptor from DFRobot. The default baudrate the wipy and lopy4 comes up in in programming mode is 115200 and it can connect fine like that, and the old update tool worked fine when I forced it to use that instead of 57600. For whatever reason the baudrate switching has never worked for me, probably it only works on the Pycom programmer boards.
-
@colinza It seems that the adapter is the problem. And using it seems strange also for another reason: the Atmega runs at 5V with 5V signal levels. That is beyond the recommended input levels of the ESP32. There is a serial resistor which limits the input current, but still it is out of spec.
Better use an adapter with USB/Serial chip made for purpose, which also can provide 3.3V output levels. -
@robert-hh The one I have has a jumper for 3.3V which I use. Also as I said it does work completely fine, and I've updated modules with it in the past perfectly, it's only that the new update software seems a bit "too user friendly" by not letting you change the baud rates or know what it's trying to do. As I say, this just seems very short sighted. I don't see why Pycom should require their own special programmer boards to get things done, the AT8U2 adaptors are ubiquitous and TTL serial should respect the standards (or just put a USB connector on the board already like the NodeMCU does...)
-
@colinza According to the schematics, the ATMEGA always runs at USBVcc = 5V, which means, it's output levels are 5V. Only the Vcc output pin is affceted by the jumper.
And no, Pycom does not require to use it's board. I'm uses different USB/Serial adapters with a dedicated USB/serial chip for that purpose without any problem. Just adapters based on a CH340G chip do not go up to 921600 Baud. So it still seems like the Atmega software in your adapter is faulty. Maybe one can fix that, but it may not be worth the effort. -
@robert-hh Okay yeah that is a fair point, there is a known bug in this ones firmware with sending RST signals or something. I'll throw it in the bin and try a different one with a FTDI chip.
Hello! It looks like you're interested in this conversation, but you don't have an account yet.
Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.
With your input, this post could be even better 💗
Register Login