I have been using nodemcu-build for 8266 modules with success for several projects.
I have been trying to replicate the same development environment using SparkFun ESP32 Thing using the beta version of nodemcu-build for ESP32.
After building, downloading a build it appears to successfully flash to the ESP32 Thing. But then
it displays the following error message:
rtc_clk_init: Possibly invalid CONFIG_ESP32_XTAL_FREQ setting (40MHz). Detected 26 MHz
From my research it appears that SparkFun build these modules with 26MHz xtals, yet the standard is for 40 MHz. The error message suggests to me that the nodemcu-build for ESP32 assumes a 40MHz xtal.
Is there any way to patch to configure for the different frequency. I found a reverse situation where the problem was to patch a 26MHz generated binary to run at 40MHz.
But I'm unwilling to start patching without having confirmation as to exactly what is the correct process.
Is there any way to patch to configure for the different frequency.
Simple answer: no, not in the cloud builder.
Elaborate answer: yes, but you have to build the firmware yourself. The relevant configuration param is documented in the ESP-IDF Programming Guide at https://docs.espressif.com/projects/esp-idf/en/stable/api-reference/kconfig.html#config-esp32-xtal-freq-sel
Main XTAL frequency
Found in: Component config > ESP32-specific
ESP32 currently supports the following XTAL frequencies:
26 MHz
40 MHz
Startup code can automatically estimate XTAL frequency. This feature
uses the internal 8MHz oscillator as a reference. Because the internal
oscillator frequency is temperature dependent, it is not recommended
to use automatic XTAL frequency detection in applications which need
to work at high ambient temperatures and use high-temperature
qualified chips and modules.
Unless you plan to very frequently build firmware binaries I suggest you give my Docker build image a try: https://github.com/marcelstoer/docker-nodemcu-build/
Related
Problem
I'm looking for a way to flash an ESP32 module's memory without installing the whole IDF software suite.
Why
Because I want to integrate ESP32 onto a custom board along with a low-performance ARM-powered CPU which runs a tiny Linux distro (based on Debian), and I want to flash ESP32 from this tiny Linux distro.
I know I could use the bootloader, but who will upload the initial bootloader? I don't want to do extra steps, so my idea is to embed the ESP32 module onto my custom board, and let the Linux to flash it from factory-state (when it's flash is empty, ie. no preloaded bootloader). Or is the serial bootloader always preinstalled on all ESP32 modules (like on ESP-WROOM-32)?
Why I don't want to use IDF? Because I don't want to build or debug anything, I just want to flash myprogram.bin onto ESP32. Also, as the board is low-performance, it would take ages to download everything for running IDF.
Current state
The ESP32 module is now visible via UART (RX,TX,GND), and if I held low the GPIO0, it runs the bootloader (my current module is embedded onto a NodeMCU - but there is no USB connected, this is raw UART!):
rst:0x1 (POWERON_RESET),boot:0x3 (DOWNLOAD_BOOT(UART0/UART1/SDIO_REI_REO_V2))
waiting for download
Could I expect the same behavior (controlling GPIO0 for running the bootloader) for all ESP32 modules, or this works just because guys at NodeMCU preprogrammed already some bootloader onto it?
I'm looking for a way to flash this ESP32 preferrably without any python script.
The ESP32 has a first-stage bootloader in ROM capable of writing to Flash - that's what's printing your output. You can talk to it if you know the protocol - this is implemented by the Python scripts in ESP IDF. If you don't want to use the official implementation because it's too heavy, you'll have to write your own implementation of this protocol which scratches your specific itch. Fortunately it's more or less documented and you can likely reverse engineer any missing knowledge from official Python scripts.
Actually Espressif also provides a nice and small binary for flashing ESPs:
https://github.com/espressif/esp-serial-flasher
Serial flasher component provides portable library for flashing Espressif SoCs (ESP32, ESP32-S2, ESP8266) from other host microcontroller. Espressif SoCs are normally programmed via serial interface (UART). Port layer for given host microcontroller has to be implemented, if not available.
One more (but very important) addition:
You have to modify this repo to make it work correctly, and also you might have to upload not just your binary, but also bootloader and partition_table.
I have just finished a project using an Arduino Micro dev board and want to move to a standalone ATmega32.
I need to run this at 3.3V and I dont want to go down the overclocking road so I have an 8MHz crystal to put on it.
I still want to be able to upload sketches via USB and the Arduino compiler so I gather I need to burn a different bootloader.
For this purpose I have purchased a USBASP programmer.
I am slightly unsure of what to do next - everything I can find on the topic either relates to the ATmega328 or to burning bootloaders using another Arduino.
I have worked out that I need to modify boards.txt to point to the correct bootloader....but which is the correct bootloader for ATmega32 at 8Mhz?
Also do I need to change any fuses?
Thanks
I think you're a bit out of luck.
The ATmega doesn't have hardware USB, so I assume the bootloader is using V-USB to implement USB. That stack, being a software implementation of USB's high-speed signalling, requires at least a 12 MHz clock (higher is better).
I don't think you can run V-USB using only the internal 8 MHz oscillator.
According to the OP comments the micro is indeed an Atmega32u4, not an Atmega32 (#OP: please fix the question to match this).
Since it has onboard USB, you can use a pre-existing bootloader like the sparkfun one:
https://www.sparkfun.com/products/12587
Here you have the link to one of their products, the Arduino pro micro 3.3V (which runs at 8MHz). You can add the sparkfun arduino boards repository to your IDE and then just use the board specification for their pro micro 3.3V do upload the correct bootloader and to program it through the USB just like the usual Arduino Micro.
I'm new with NodeMCU firmware use. I have a Amica ESP-12E (v2?) dev kit connected to a DHT22 which I program using the Arduino IDE. All is setup and working fine.
My problem came when I wanted to update NodeMCU firmware. Since I don't really know what came pre installed from China, I downloaded ESPlorer to try to determine NodeMCU version. I get the following "error" when I reset the dev board:
Communication with MCU..Got answer! Communication with MCU established.
AutoDetect firmware...
Can't autodetect firmware, because proper answer not received (may be unknown firmware).
Please, reset module or continue.
{{a long string of weird characters that I can't copy and paste appear here}}
At this point I'm totally clueless about what version of firmware I have. Is there a way to obtain NodeMCU firmware version by software via Arduino IDE code, ESPlorer GUI or something similar?
On the other hand, is there a really easy way to compile/download latest NodeMCU firmware BIN file? Even one with all the modules active will be fine for me now, I'm just trying to understand and test things.
You seem to be confusing two very different platforms. I leave out some details as not to confuse you any further.
Arduino: you use Arduino programming in the Arduino IDE then build and install a binary to your device whenever the application changes. No NodeMCU firmware needed!
NodeMCU: you flash the NodeMCU firmware once (e.g. using esptool.py) and then upload Lua code (e.g. using ESPlorer) whenever the application changes. This is more lightweight than the Arduino platform.
On the other hand, is there a really easy way to compile/download
latest NodeMCU firmware BIN file?
Yes, have a look at the NodeMCU documentation at http://nodemcu.readthedocs.io/en/latest/en/build/. The easiest is to use the cloud builder at https://nodemcu-build.com/. I currently suggest to build from the dev branch because flashing is easier with it.
As pointed out you have several options for firmware and you'll need to make a choice as to which suits you going forward. If you are going to stick with the Nodemcu LUA firmware you can determine the version by typing:
print(node.info())
at the command line prompt.
There are alternatives to using ESPlorer e.g. Putty or Coolterm that will give you the raw output from the device with no interpretation. So if you have the correct serial port settings and the device plugged into the USB port it will show the banner when you reset giving an indication of the origin and version of the installed firmware.
In ESPlorer, there is an option under settings which if unchecked will stop looking checking for the version of the code.
For whatever reason, ESPlorer is not designed to read nodemcu version.
The error message throws you off, could lead you to think, there is an error.
At best, the above error can be ignored. It has no impact at all. In background, init.lua is up and running.
I'm having trouble with an industrial Linux computer I'm working with to achieve communication over an RS485 bus with multiple connected devices. What I've encountered is that the IO pins used by the RS485 USART driver are set to different levels at startup instead of going to the RS485 idle/tri-state. As a result, the other devices on the bus are blocked for more than 30 seconds while the device boots up, triggering all sorts of external problems. The course of events can be viewed in the attached image, where I've measured the output voltages with an oscilloscope during startup.
My guess is that the actual driver is not started until the voltage levels reach their tri-state levels (e.g. ~2.2V for this device). After that everything works as expected.
I've tried to find any config-files to set the default IO level of the pins at boot (thinking this may be set by the bootloader) to no avail.
Also, I've tried to apply a startup-script to run "early enough" to set DATA- high, but the device in question does not provide any interface to control these pins as regular GPIOs as far as I can tell.
Any help, tips or insights would be much appreciated!
EDIT: I am not an experienced Linux developer, so please highlight if I've left out any important details.
Some specs:
ARM920T rev 0 (v41) CPU
Proprietary distribution of Linux 2.6
Uses Busybox
Atmel USART drivers
Extract from boot log:
Linux version 2.6.28.10 (root#) (gcc version 4.1.2) #94 PREEMPT Tue Oct 29 10:22:19 CET 2013
CPU: ARM920T [41129200] revision 0 (ARMv4T), cr=c0003177
/...
.../
RS485 mode for port /dev/ttyS3 enabled
/...
... (I'm guessing the ~30 secs elapse here)
.../
atmel_usart.3: ttyS3 at MMIO 0xfffcc000 (irq = 9) is a ATMEL_SERIAL
atmel_serial.3: Putting the RS485 RTS pin down
/...
...
.../
Full boot log: https://drive.google.com/file/d/0B2XYl1mNCa8jNUZ5V0Nic1hkU0U/view
Similar issue:
Possibly a similar issue is discussed here: UART initialisation: Prevent UART to pull RTS high
But I'm not sure how to proceed with the suggested solution.
This is little more than wild speculation, but it might be worth adding a start-up script that echoes a NULL character to the device (e.g. /dev/ttyS1 or whatever) as early as possible during start-up. This might be enough to kick the driver into initialising the hardware.
You could also try to locate the driver in the Linux source to look at how it starts up.
Probably you have access to the source code, so you can investigate who and when mess with the that GPIO. Just grep the kernel source for the atmel gpio controller port addresses to figure out what happen. If you are lucky may be there will be kernel command line option that you can pass from the bootloader to set the line to what you need in advance.
this answer may work if you can find required things mentioned below
of your board!
Once I also had a same issue on PWM. There I found that my bootloader was responsible for the same, I changed in bootloader configuration and it started working fine.
Check your BSP provided by board vendor or third party (If you have the source), If your bootloader is U-boot you can find it inside U-boot-(source)/include/configs/(your-board).h there you can find configuration for RS484. As per your datasheet for the board you can check for other things which are muxed on the same pin and disable those if not required for boot time and enable RS485.
enabling/disabling can be done by changing the values 0, 1 or 2 as per your configuration and also you can simply disable anything just by commenting // out the line.
I'm working with an 8051 (Cypress FX2LP) that doesn't have jtag/bdm capability. Typically, developers on this project have been using ad-hoc serial printfs for debugging. I'm looking into options for serial debug monitors such as Keil's Mon51, Isd51 or IAR's generic ROM-monitor.
I'll need to modify/configure this debug monitor to write to code RAM (to set software breakpoints). I'd guess that most 8051 debug monitors offer the ability for such modifications in order to support Harvard architecture or bank switching.
Does anybody have recommendations for serial debuggers for 8051 or similar processors?
Have you had to modify it to write to Harvard code RAM or flash etc?
I used for years Keil uVision PK51 and the Cypress FX2 EZ-USB Development kit. This kit (EZ-USB_devtools_version_261700.zip) worked correctly with FX2 and FX2LP.
It includes a Windows driver that automatically downloads the monitor firmware on board and stay resident in 8051 memory. This monitor takes control of one of the 2 serial board and manage the communication with the debugging tool. You have to set the Keil environment debugger to use the "Keil Monitor-51 driver".
Once your fw is downloaded and running you can set breakpoints, display watch, etc...
The Cypress driver works correctly with Windows 2K/XP. I never tried it with Vista or later. Probably there is a newer version of the Cypress that is able to run on the latest Windows.
Good luck
I have been using Mon51 with the Cypress FX2 for going on 10 years with very good success. In addition we use the RTXtiny task switcher and code banking. I have found the monitor to be generally solid and with enough functionality for our needs.
The Mon-51 code comes as a library from Keil, so it is not available. A couple of years ago I was having trouble getting code banking to work with the monitor, and since I wasn't getting very good support from Keil, I started to disassemble the monitor to figure out what was going wrong. Before I got very far I solved my problem and I never finished the reverse engineering project.
Our hardware platform is "von-neumanized" so that code and xdata space overlap. This is necessary for the monitor to work correctly. We have modified the monitor initialization code so that it runs at 115200 baud from an external uart and that works well. In addition we had to build our own version of the monitor so that it was located at a different location in memory. Keil has actually made it pretty easy to configure things without having to dive into the actual monitor code.