"Heap init code improvements" doesn't boot on ESP-01 with PUYA flash #8657
Comments
|
Default baudrate is 74880 btw, you will see boot messages if you configure your monitor to it |
|
Thanks for the quick response!
Decoding at 74880 bps gives the following (repeating in an infinite loop):
I've now tried a few other ESP-01 modules and found one that works with the commit!
Both should have 1 MB Flash (25Q80). One interesting difference I see between these two modules is time to erase the flash: Good module: Bad module: In both cases Arduino was set to "Erase flash: All Flash Contents" |
|
Usually, device prints something like this on boot Not actually erasing flash seems suspect, and ours as well as esptool issue tracker mentions PUYA chips as source of all kinds of trouble. While we have PUYA-specific workarounds for an already working sketch (edit: enabled by default), not really sure this is the expected behaviour when flashing or whether it actually writes any data to the flash. Looks like a hw issue, really. |
For some reason all my instruments have problems decoding this serial output. I've finally managed to get something halfway readable using pulseview on an CSV export from a logic analyzer. Serial output from the bad module: Unfortunately the exception decoder doesn't seem to do anything with this, even if I just paste the part that looks correctly decoded. EDIT: 0x40201ec8 is handle_hwdt
The PUYA issues all seem to be related to writing to flash (to filesystem during run time, or with esptool during programming). I always get "Hash of data verified.", on both the good and the bad module. If this is an issue writing the flash during programming, shouldn't the verification fail at this point? I don't see how the heap code changes anything related to flash writing. For the record, flash_id of chips on my modules: Good module: Bad module: One idea I had is that maybe the PUYA work-around code itself is a problem, since it might get run on the bad module (due to its flash_id), but not the good one. I see that the workaround malloc's an additional buffer so that might be the connection to the heap code. On the other hand, I don't see why the boot code would want to write to flash early in the boot process. |
|
@avian2 /*@create-file:build.opt@
-DUMM_INIT_USE_IRAM=1
*/Also, remove For confirmation that the new In the Arduino IDE build console. To see a detailed build report, you may need to turn on "Show verbose output during compilation" These changes will remove early (pre SDK init) ICACHE read operations. |
|
@mhightower83 Thanks for the suggestion. Adding this define makes the Blink sketch work on the bad modules! Bad module, unmodified git master (313b3c0), with Bad module, unmodified git master (313b3c0), without I tried alternating the setting three times to make sure it's not random. @mcspr Some additional info regarding flash writing: I manually dumped the flash content from the modules with Also, the unused portion of the flash looks correctly erased (all As far as I can see, this is not a problem with programming the flash with the esptool. |
|
Hm. But what's the difference between flash cache being enabled later down the line vs. manual call in that wrapper? |
|
@mcspr |
|
In case it helps in understanding this issue, here's another partly decoded serial capture I have. This was triggered from the RST line, so it shows serial output immediately after reset: 0x40223968 is the address of the |
|
Sorry, I looked around and I don't have any devices with the PUYA flash chip. If you don't mind here is another experiment to try. Add this as a new #include <Arduino.h>
#include <umm_malloc/umm_malloc.h>
extern "C" {
#include "user_interface.h"
#include "cont.h"
}
extern "C" {
/////////////////////////////////////////////////////////////////////////////////
// starter code copied from core_esp8266_main.cpp
extern "C" void call_user_start();
IRAM_ATTR void app_entry_redefinable(void)
{
/* Allocate continuation context on this SYS stack,
and save pointer to it. */
cont_t s_cont __attribute__((aligned(16)));
g_pcont = &s_cont;
flashchip->chip_size = 1024 * 1024; // Fixup chip_size for PUYA
/* Doing umm_init just once before starting the SDK, allowed us to remove
test and init calls at each malloc API entry point, saving IRAM. */
#ifdef UMM_INIT_USE_IRAM
umm_init();
#else
// umm_init() is in IROM
mmu_wrap_irom_fn(umm_init);
#endif
/* Call the entry point of the SDK code. */
call_user_start();
}
}; |
avian2
changed the title
|
@mhightower83 I tried the chip_size fixup and there is no difference. I verified that the code gets compiled in by dumping the elf, but it still crashes on boot. |
mcspr
added
type: bug
help wanted
|
@avian2 Thanks for trying that. I have been looking around a bit and see this equivalent used before starting If this should fail, I may need to wait till I have hardware to work with to resolve it. I would also look at a roll-back PR. #include <Arduino.h>
#include <umm_malloc/umm_malloc.h>
extern "C" {
#include <user_interface.h>
#include <esp8266_peri.h> // **** new line ****
#include <cont.h>
}
extern "C" {
/////////////////////////////////////////////////////////////////////////////////
// starter code copied from core_esp8266_main.cpp
extern "C" void call_user_start();
IRAM_ATTR void app_entry_redefinable(void)
{
/* Allocate continuation context on this SYS stack,
and save pointer to it. */
cont_t s_cont __attribute__((aligned(16)));
g_pcont = &s_cont;
SPI0U |= SPIUCSSETUP; // SPI_CS_SETUP - **** New line ****
// flashchip->chip_size = 1024 * 1024; // Fixup chip_size for PUYA
/* Doing umm_init just once before starting the SDK, allowed us to remove
test and init calls at each malloc API entry point, saving IRAM. */
#ifdef UMM_INIT_USE_IRAM
umm_init();
#else
// umm_init() is in IROM
// I am not sure what this does. It appears to be the key function called
// from `fix_cache_bug` in the NONOS SDK - Will this help PUYA Flash work?
// It appears to do some, low-level undocumented register manipulation and
// device specific init based on OTP CHIPID model bits.
extern uint32_t phy_get_bb_evm(void); // undocumented
phy_get_bb_evm();
mmu_wrap_irom_fn(umm_init);
#endif
/* Call the entry point of the SDK code. */
call_user_start();
}
};Edit: I think the |
|
@mhightower83 Thanks for looking into this. I've tried the SPI_CS_SETUP fix and unfortunately Blink still does not boot with PUYA flash. Same as before I get an invalid instruction exception in I've also tried ESP-01 modules with BergMicro and Kynix flash chips. Those work fine. |
|
@avian2 I will not be able to test this on a device with PUYA flash until after October. The hardware devices I received so far, that were supposed to have PUYA flash, have Tenx. |
Pfft, you can't rely on getting garbage chips when you purposely order garbage... |
|
@mhightower83 Your latest code from 08/30/22 with I also tried it with modules with BergMicro and Kynix flash that I have at hand and they work fine. Thank you again for taking the time to investigate this problem! |
d-a-v
added
alpha
|
@avian2 It looks like there is still a missing piece to recreating this problem. I have now swapped in the PUYA P25Q80H flash chip on an ESP-01S board and the failure does not occur with the blink sketch with core version ((313b3c0...)) or the current master. So I am failing to recreate the original problem. I think I have gone as far as I can with this. It is working for you. The logic came from a function named If you have time to try the fix in PR form #8658 (comment), that would be great. Otherwise @d-a-v, I think I am done with this PR. Edited for clairity. |
|
Sorry, I keep meaning to follow up on this but other things kept interfering. @mhightower83 I'm not sure what's special about PUYA P25Q80H on my modules. Perhaps I have some other die revision? Or maybe the ESP8266 itself is different? Unfortunately I only have one of them left for testing. Others are running some sensors for me (without problems so far - I used then-current esp8266 core with the heap init code commit reverted). In any case, the current git master (80bf716) works for me on the PUYA module I still have, so I can confirm that your last PR fixed it. I also checked again just to be sure it's not something else: the issue is indeed still perfectly reproducible with the old core version I initially reported (313b3c0). Thanks again for your help! |
Basic Infos
Platform
Settings in IDE
Problem Description
Any program compiled and uploaded using the latest git master does not run at all. After a successful compile and upload Arduino serial monitor only shows garbage (using a scope on the serial line shows data with a non-standard baudrate that I can't decode). The LED is constantly on.
Simplest sketch that reproduces this is the "Blink" example. However the result is the same regardless of what program is uploaded.
Using git bisect from a known-good release (2.4.2) shows that the commit that introduced this issue is:
7356cd1
Heap init code improvements and updates (#8458)
Reverting just this commit on the latest git master fixes the problem.
MCVE Sketch
Debug Messages
The text was updated successfully, but these errors were encountered: