SHA2017-badge/Firmware

Update to esp-idf 3.0

Closed this issue · 5 comments

Hi,

I am wondering if anybody succeeded using the SHA2017-badge/Firmware running on badge Rev1.0.* with the recent esp-idf (ESP-IDF Pre-release 3.0-rc1 as of today) and the updated toolchain (1.22.0-75-gbaf03c2-5.2.0).

To make the compilation complete I had to change WIFI_COUNTRY_EU to WIFI_COUNTRY_POLICY_AUTO in badge_first_run.c

Unfortunately the display does not work. The touch pad works. Setting Enable eink debug messages in menuconfig does not bring additional information:

ets Jun  8 2016 00:22:57

rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff0018,len:4
load:0x3fff001c,len:4468
load:0x40078000,len:0
load:0x40078000,len:12976
entry 0x40078d88
D (157) badge_eink_dev: init called
D (157) badge_eink_dev: init done
badge_eink_dev: EPD-Busy Int up
Button START handling
Selected 'mpr121 touch demo'

Do you have any ideas where to look for possible issues with operation the the display?

My badge works without any issues loaded back with original firmware. Congratulations on building this impressive project complete with the hardware!

basvs commented

I had the same issues when I was trying to update the esp-idf code.

In the components/badge/badge_eink_dev.c we use some magic to setup and control the SPI bus. This doesn't work anymore with the newer esp-idf code. I guess that either one of the settings is overwritten when configuring another SPI bus, or we have to set another setting which was previously already set.

I guess the best way to fix this is to switch to the spi-functions defined in the esp-idf.

basvs commented

@Spritetm do you know which change broke the low-level magic SPI code we use? :)

Hi @basvs,

I have switched to the spi-functions defined in the esp-idf as you suggested.

This was a very good idea and the badge works great!

When looking though the configuration I have noticed the menuconfig setting [*] Run FreeRTOS only on first core. Do you know what is the reason of this limitation?

@krzychb I don't remember exactly, but if I recall correctly we found that some parts of the codebase (perhaps uGFX or the BPP infrastructure?) did not work reliably with FreeRTOS running on both cores. Would be interesting to get to the bottom of that though!

I see it resolved in 9e78ab3 👍