I am trying to develop the Firmware Over The Air(FOTA) for the STM32(L4-Series) controller as IoT application. I have little bit confused in below topic/section that how it work & goes:
How to build the bootloader & load it into controller?
how to download the new firmware code(from over the air i.e updated Firmware)?
And how to identify the newer and older version's of code?
I am writings steps to do so, but it seems you just started this
Get bootloader code of the controller, you will need it to customize the code.
your firmware (old) will download new firmware, copy it into an inactive area and it will set a flag and then it will perform a software reset.
After reset, the bootloader will check flag if set it will copy the
new firmware from the inactive area to active area. So new firmware is
active now.
The reason why old firmware will download the new firmware is that we want to keep the bootloader code as minimum as possible. So, the application process the new firmware maybe by CRC check. And to upgrade the firmware OTA you need to verify that your new firmware is 100% correct otherwise a single bit error can cause severe problems.
Related
For all of these scenarios, I am able to upload the firmware and monitor via serial usb. But after creating my first firmware, for all new firmware, I can't upload Lua scripts using the nodemcu-tool without getting the following:
Error Message
F:\Development\NodeMCU\helloworld>nodemcu-tool -p COM3 upload init.lua
[NodeMCU-Tool]~ Unable to establish connection
[NodeMCU-Tool]~ Invalid node.chipid() Response: 6935962
Observations
Can reset the board using nodemcu-tool. Leads me to assume the baud rate is fine.
Can see the file system being created from PuTTy after loading any of the firmware. Leads me to assume the firmware is OK.
Have tried multiple dev boards, same results
Found the source of the error message device-info.js. either line 45 or 49
I have no idea what "Response: 6935962" means. Is that my chip id or an error code?
A new commit was made to the firmware source during the last couple of days. No idea if this is relevant.
Was hoping to get this resolved before I go down the Docker rabbit hole. Lazy. I know.
9/6/2019 - created first firmware to start development
Built a firmware using https://nodemcu-build.com/ with these modules (cron, file, gpio, i2c, mdns, mqtt, net, node, sjson, tmr, uart, wifi)
Uploaded the firmare using NodeMCU-PyFlasher-4.0
No issues with this firmware. I've been able to upload lua scripts and test them successfully. Even now, I can revert back to this firmware and use it without issues. I've even redownloaded this firmware from the original link, and it works fine.
9/7/2019 - created a new firmware to use adc and other goodies
Built a firmware using https://nodemcu-build.com/ with these modules (adc, cron, file, gpio, i2c, mdns, mqtt, net, node, rtctime, sjson, tmr, uart, wifi)
Uploaded the firmare using NodeMCU-PyFlasher-4.0
Having the problem described above.
9/8/2019 - built firmware with minimal modules
Built a firmware using https://nodemcu-build.com/ with these modules (file, gpio, net, node, tmr, uart, wifi)
Uploaded the firmare using NodeMCU-PyFlasher-4.0
Having the problem described above.
Platform & Tools
Windows 10
Development board: HiLetgo ESP8266 NodeMCU LUA CP2102 ESP-12E Internet WiFi Development Board Open Source Serial Wireless Module
Firmware builder: https://nodemcu-build.com/
Serial Monitor: PuTTy 0.72
Firmware Loader: NodeMCUPyFlasher 4.0
Lua script loader: nodemcu-tool 3.0.2
fetchDeviceInfo() first calls node.info() at https://github.com/AndiDittrich/NodeMCU-Tool/blob/master/lib/connector/device-info.js#L9. Then it does an if-else to figure out whether it's running on ESP8266 or ESP32.
With the recent upgrade to SDK 3.0 node.info() was changed in PR #2830. See documentation at https://nodemcu.readthedocs.io/en/latest/modules/node/#nodeinfo. It now returns values the script doesn't consider to be coming from ESP8266. The script then calls node.chipId() in the else branch. So, it's getting a chip id from ESP8266 but it is expecting one from ESP32. Hence, the exception.
I have no idea what "Response: 6935962" means. Is that my chip id or an error code?
It's your chip id.
To cut a long story short: NodeMCU-Tool needs to be adjusted as laid out above to work with the current NodeMCU version.
I cached the same issue from the recent cloud build(https://nodemcu-build.com/). It works when i switch back to the old ones. It looks like a problem of the build system or recent source code. You can switch to other build method and try use the older code.
So I've got a Mikrotik RB, which has the Bleeding edge (unstable version) installed on it. I know it is kinda stupid to use OpenWRT on RB, but I need it for UDPxy.
Anyways, the guy wants me to enable Luci and UDPxy, but he installed the unstable version of OpenWRT and now he wants me to do the stuff above.
I just want to know, can I flash the stable version on it? Is the procedure same as for the upgrading? Is there any differences while flashing if I use a board that didn't have OpenWRT as firmware?
Downgrading is the same as upgrading, in either case you are just flashing new firmware onto the board. The only thing that may differ is the configuration files may be kept and may need to be reset when downgrading.
However this is easily done.
Regarding your last question, there may be differences depending on your board. Usually its just a case of finding the hidden restore interface and flashing it. But please consult your device's page on the OpenWRT/LEDE page for more information.
Background: We are looking to release a commercial product based on the Android Things OS and Pi 3 hardware. The OS seems to become corrupt over time. Usually after several weeks of continuous testing. By corrupt, the Android screen will no longer appear on startup and putting SD into new hardware does not remedy. We are using an application Factory Image base on the 0.5.1-devpreview created in the Console.
My question: Is there a way to debug or monitor what caused this state in the OS? Direct serial connection?
try to clean the sd card with the diskpart command and start again from scratch.
And to debug, maybe a USB to TTL cable may help. As explained here.
Regards!
For a project I need wps support in the nodemcu firmware. To enable that I have added wifi.wps.* commands in app/modules/wifi.c and I have added -lwps to the Makefile in app. All builds well, but after flashing the firmware I get problems in that the firmware reboots in a loop.
Commenting out the calls to libwps.a and only having the lua commands in place makes the problem disappear. Is there a know issue, why there is no wps support in nodemcu?
I have a clone of the nodemcu git repository and a docker build environment for building the firmware.
Arnulf
Found the problem myself. There seems to be a limit of the firmware size of 512 KB. I removed some modules when building to stay under that limit and then all worked as expected :)
Found out that if I use the ESPTOOL_FS environment variable of esptool.py to set the correct flash memory size, the firmware size can be greater than 512K and there are no problems starting the module.
I am having some trouble updating UMDF drivers using "devcon" during a
standard code-deploy-debug cycle. The problem is that "devcon update" isn't
really updating anything unless the version number or the date of the DLL
file and the INF file has changed from what is stored in the system's driver
cache folder. After a maddening series of experiments I've discovered that
one way to force the thing to use the latest files is by doing the
following:
Change the parameters passed to
"stampinf.exe" in "makefile.inc" by
explicitly setting a version with
the "-v" option.
Modify the
resource script file ("DRIVER_NAME.rc") to first define
VER_USE_OTHER_MAJOR_MINOR_VER
before including "ntverp.h" and then
explicitly define
VER_PRODUCTMAJORVERSION and
VER_PRODUCTMINORVERSION. You'll
note that this system does not allow
us to change the build and the
revision numbers. On Win7 this
seems to be fixed at 7600 and 16385
in "ntverp.h". Is this by design?
So, I first modify "makefile.inc" and set the "-v" option to something like
"1.1.7600.16385" manually incrementing the minor version for every single
build and then modify the RC file and update VER_PRODUCTMINORVERSION with
the same number.
Alternatively, if I run a command prompt under the SYSTEM account and go and
delete the driver cache folder in
"C:\windows\system32\DriverStore\FileRepository\DRIVER FOLDER" before
running "devcon" then that works too.
Now, I am thinking I am missing something fairly basic here as this seems to
be a rather painful way of doing it. Please help! Thanks!
Why can't you just unplug the device and replace the unloaded DLL? You shouldn't need to reinstall the driver, just replace the module. Note that you shouldn't do this during production or anything that has to do with customers, but if you're writing a driver, just slam in the new module with the same version number.
On Win7 this seems to be fixed at 7600 and 16385 in "ntverp.h". Is this by design?
Yep, at least until the next service pack
As Paul Betts has suggested above, the way to go seems to be to simply replace the UMDF DLL directly in the driver folder (for e.g. c:\windows\system32\drivers\umdf\) after disabling the device either in the device manager or using "devcon". I'd asked this question on Microsoft's device drivers newsgroup before posting here but hadn't got a satisfactory response - but some folks ended up responding there after I posted here! So I'll put up a link to that post as well:
http://bit.ly/6PDxKT