I have an ESP32 board with GPIO0 connected to ground through a switch. The idea is that if I press the button and issue an ESP.restart() the board would get into flash mode.
Instead, ESP.restart() just restarts the app, ignoring GPIO0 state.
Is it possible to force the whole boot process, maybe with a direct JMP to the HW reset vector?
According to Ivan Grokhotkov
On ESP32 there are 3 reset reasons which cause strapping GPIOs to be sampled: power-on, RTC WDT reset, brownout reset.
So in terms of code, see below. If the pin is strapped it will never get out of the bootloader which will be waiting for a sync on serial.
#include "soc/rtc_wdt.h"
void hardReset() {
rtc_wdt_protect_off(); //Disable RTC WDT write protection
//Set stage 0 to trigger a system reset after 1000ms
rtc_wdt_set_length_of_reset_signal(RTC_WDT_SYS_RESET_SIG, RTC_WDT_LENGTH_3_2us);
rtc_wdt_set_stage(RTC_WDT_STAGE0, RTC_WDT_STAGE_ACTION_RESET_SYSTEM);
rtc_wdt_set_time(RTC_WDT_STAGE0, 10000);
rtc_wdt_enable(); //Start the RTC WDT timer
rtc_wdt_protect_on(); //Enable RTC WDT write protection
}
A better solution is that not using firmware update mode for programmatically software updates, use it only for only bootloader updates. Split your code into two-part bootloader and logical program part.
To update your logical program part, your bootloader should handle burning the remaining addresses except for the bootloader. (Your bootloader code can burn any address on the microcontroller, filesystem libraries do that) So don't try to switch into firmware update mode which is available for whole firmware updates. The more advanced solution is using OTA update features as possible as.
In this way, you guarantee that you always have the bootable device in the field, which is ready to update any corrupted logical part. Any mistake during burning the bootloader in the field may cost your device shipment.
Related
The program builds fine, but when I tried to flash code from snap debugger to PIC16F15313 in MPLAB its giving this error. Even though low voltage programming is enabled in code.
"MPLAB has detected that the low voltage configuration bit on the device is off. Because Snap can use only low voltage programming, this configuration bit must be turned on in order to use Snap. You will need to use a different, blank device, or use another debug tool to erase this device, before continuing with Snap.
Connection Failed."
I had same issue. My problem was in the wiring of debugger (one wire was not connected). I think that your problem may be similar. LVP should be set in new device by manufacturer.
Two issues:
Switch on low voltage programming:
#pragma LVP = ON
check the wiring:
Note: The MPLAB Snap In-Circuit Debugger is powered through its Micro-B USB connector. The target board must be powered from its own power supply. The debugger sense the target voltage.
I'm using an ATmega328p microcontroller with the optiboot bootloader.
Optiboot is configured to flash a "start LED" for 3 times when optiboot is running.
Fuse bits are set for a bootloader section of 256 words and BOOTRST is programmed to jump into the bootloader section at start-up.
With the bootloader installed, I flash the actual firmware via the UART (pin 30 and 31) and that all works fine.
Now to my question:
When my firmware is running and I pull the reset line of the atmel to GND, I can see the "start LED" flash 3 times and then the firmware execution starts. This tells me that the bootloader run right after the reset.
However, when I start-up the atmel (supply power to the chip), I do not see the "start LED" flash 3 times and the firmware code seems to be executed right away.
Does anyone have an idea why optiboot flashes the "start LED" after pulling the reset line to GND and not when I power-on the chip?
The reset line is directly connected with a 10k pullup to the supply voltage of the atmel.
I hope someone has an explanation and any help is much appreciated.
i think it's relevant ,
"On reset, Optiboot starts and reads the reset reason from MCUSR. For any cause other than "external reset", the application is started immediately. Otherwise, optiboot attempts to download new application software"
I have an AOSP tree compiled on my board. I bought a wireless keyboard and connected it to my board via usb port. I expect when the board is in the suspend state, it will wakeup by pressing a key on keyboard. But it is not so.
I tried several ways in my bootloader (uboot), kernel, etc. But no effect. Additionally I made an experiment and found out that in the sleep state, my usb port (which has a dongle in it) has just 1-5 mA. But it should be higher for the dongle to work!
Has anyone experienced this? How to enable remote wakeup for usb in android?
Thanks
More info:
The uboot supports usb host controller interface. I tweaked kernel build options. but these two actions has no effect.
EDIT : I work on p212 reference board of amlogic. Its SoC is Amlogic S905X.
EDIT 2 : I tested the board (which is a tv box actually) using my phone and its charger and I found that when the box goes to sleep, the charging is stopped!! So I can deduce that the dongle has not enough power to stay alive! (yet to send wake signal to SoC !)
Then I carried out a second experiment: I connected the phone using a USB charger which only has two pin instead of four. (Just voltage supply; differential pins (signal pins) are disconnected). The result: my phone is charging now!! It seems when the SoC is suspending, it sends a signal to USB peripherals telling them to not draw power. Am I correct? How can I configure my AOSP tree and Linux kernel and uboot bootloader to avoid happening this?
Please guide me how to fix it in kernel or other parts of stack!
EDIT 3 :
I have pasted my kernel config here. I configured these options to y but has no effect:
CONFIG_PM_RUNTIME=y
CONFIG_PM_AUTOSLEEP=y
CONFIG_PM_DEBUG=y
CONFIG_USB_OTG_WAKELOCK=y
CONFIG_USB_DEBUG=y
CONFIG_USB_OTG=y
Also this link is my device tree files. (in kernel. NOT uboot)
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 have a Freescale imx.6q (arm) based board.
Hardware is configured with devicetree.
It had a change major incompatible change to timings and voltage for an onboard fpga, but these changes are invisible to the kernel.
The EE's tell us we shouldn't load the old fpga firmware for fear of damaging it. I would like to support both hardware from the same code (It is already causing confusion)
The solution I have thought of is this:
There are several new spi temperature sensors on the board. If I can read from one of those devices, I can infer that I need the new firmware.
How can I (in one driver) grab an spi device and then release it?
I suspect that I might be able to do something like this with device tree,
But I don't want to make the device unavailable.
Any ideas or examples of something like this being done?
After reading question i think your concern is how to add software support for more than one hardware.
If that is the case i think we can write two drivers supporting both hardware's with different configuration such as irq, voltage, register set etc.
So i will enable both drivers in Makefile and config file.
So at the time of boot when probe of drivers gets called we can check the hardware id by using spi_read command from driver.
If hardware id matches then driver probe gets successful and driver can be used to interact with hardware.
If spi_read fails then driver probe itself will fail.
I think this will do the trick.
EDIT (answer the question)
To detect use an SPI device from another driver use a reference to the device in the devicetree structure.
Short answer: add a reference to the spi device in your devices dts entry.
Slightly longer answer:
When adding spi to another device driver, you are effectively adding a subdevice, which may want its own driver. I have an FPGA which loads its firmware over (something close enough to be considered) SPI. I started with the idea of just treating the spi device as part of the larger driver, but the more work went into it, the more obvious it was that it is its own device, with a purpose and function that is distinct from the rest of the driver. I separated that code into its own driver.
Now instead of a reference to an SPI device, my driver just has a reference to an FPGA Manager device.
See line 98, 370 of https://github.com/d4ddi0/linux/blob/v4.12evi/arch/arm/boot/dts/imx6q-evi.dts
and
make sure the spi driver is loaded before your driver completes loading
My original answer to my question (for historical purposes):
What I ended up doing was using different devicetree files. The difference is know at initial install time (based on the serial number). The bootloader knows which dts filename to load.
There are multiple FPGA firmware versions and the right one is chosen based on the description in the dts.
This way, I can still update the driver and/or dts without breakage.
This works well in practice even though it does not detect anything at runtime.
One problem still exists, if I take an SD card from a new revision, and put it into an old one, the incorrect firmware will be loaded. To really solve this last problem, we've talked about adding an EEPROM to uniquely identify the hardware revision on future boards.