Closed RudolphRiedel closed 1 year ago
Ok, found the issue, it is required for eve_flash_pico.uf2 to work to actually have a display connected to the Pi-Pico first.
And I ran into the next issue. I connected a RVT50HSBNWN00 with a BT817 and it works with my software on the Pi-Pico after I configured PD to pin 7.
I was using BT815-unified.blob and BT817-unified.blob from this repository. BT817-unified.blob is 100% the same as EVE Asset Builder\tools\BT817-unified.blob and EVE Asset Builder\flash_blob\bt817.blob in EAB 2.8.0 - it does however not work. BT815-unified.blob from this repository is the same as EVE Asset Builder\tools\BT815-unified.blob. However, EVE Asset Builder\flash_blob\bt815.blob is a totally different file.
CMD_FLASHERASE python uf2conv4eve.py -f BT815 bt815.blob -i flash.bin -> works
CMD_FLASHERASE python uf2conv4eve.py -f BT817 bt817.blob -i flash.bin -> does not work
python uf2conv4eve.py -f BT815 bt815.blob -i flash.bin -> works
python uf2conv4eve.py -f BT817 bt817.blob -i flash.bin -> works
CMD_FLASHERASE python uf2conv4eve.py -f BT817 bt817.blob -i flash.bin -> does not work
python uf2conv4eve.py -f BT817 bt817.blob -i flash.bin -> does not work
python uf2conv4eve.py -f BT815 bt815.blob -> does somewhat work but the flash data is not correct
python uf2conv4eve.py -i flash.bin -> works
python uf2conv4eve.py -f BT817 bt817.blob -> still works
Reading back the flash with EAB 2.8.0 and a MPSSE adapter reveiled though that the bt817.blob was actually not written to the flash, the bt815.blob is still there.
CMD_FLASHERASE python uf2conv4eve.py -f BT817 bt817.blob
Reading back the flash with EAB 2.8.0 and a MPSSE adapter does not only result in a 16 MiB file instead of the 64 MiB expected file, the file also is completely empty - filled with 0xff.
I generated a new flash image now with /flash_blob/bt817.blob. I flashed it with EAB, I checked the .bin, I read it back, the first page is from bt817-blob.
I switched back to the Pi-Pico - the software works.
CMD_FLASHERASE Flashing the new flash image with EAB 2.8.0 and the Pi-Pico. -> does not work Reading back the flash image with EAB and MPSSE -> the flash image is completely empty - filled with 0xff.
For some reason uf2conv4eve.py and uf2conv4eve.exe do not write the b817.blob to an empty flash.
When I drag eve_flash_pico.uf2 into that drive it vanishes and does not come back as "BTEVE-FLASH". Ok, found the issue, it is required for eve_flash_pico.uf2 to work to actually have a display connected to the Pi-Pico first.
Hi RudolphRiedel, the eve_flash_pico.uf2 require Pi-Pico connecting to an EVE, no need LCD.
However, EVE Asset Builder\flash_blob\bt815.blob is a totally different file.
EAB developer recommend using blob files in "EVE Asset Builder\flash_blob"
For some reason uf2conv4eve.py and uf2conv4eve.exe do not write the b817.blob to an empty flash.
Please share me how you send CMD_FLASHERASE? By the way, the eve_flash_pico.uf2 does not support updating the blob file yet. I will add this feature later.
Ok, found the issue, it is required for eve_flash_pico.uf2 to work to actually have a display connected to the Pi-Pico first. Hi RudolphRiedel, the eve_flash_pico.uf2 require Pi-Pico connecting to an EVE, no need LCD.
Yes ok, I only do not have an EVE board that is not connected to a display, I am exclusively using complete modules.
However, EVE Asset Builder\flash_blob\bt815.blob is a totally different file. EAB developer recommend using blob files in "EVE Asset Builder\flash_blob"
Ok.
For some reason uf2conv4eve.py and uf2conv4eve.exe do not write the b817.blob to an empty flash. Please share me how you send CMD_FLASHERASE?
I was using EAB and a MPSSE adapter. But switching between the MPSSE and the Pi-Pico is not something I like to do more often than necessary. :-) So I also used EVE_cmd_flasherase(); from my library.
I erased the flash again and python uf2conv4eve.py -f BT817 bt817.blob -i flash.bin is not working.
I tried this: python uf2conv4eve.py -p -f BT817 bt817.blob -i flash.bin And now that flash is programmed with my flash image and my software works.
Including EVE4 firmware blob bt817.blob Launching H: (BT8XX-RP2040-v0.0) Setting SPI pin: [['MISO', 4], ['CS', 5], ['SCK', 2], ['MOSI', 3], ['INT', 6], ['PWD', 7], ['IO2', 14], ['IO3', 15]] spin= MISO: 4 CS: 5 SCK: 2 MOSI: 3 INT: 6 PWD: 7 IO2: 14 IO3: 15
100%|████████████████████████████████████████████████████████████████████████████████████████████| 8/8 [00:00<?, ?kB/s] Wrote 67 bytes to H:/SPI_PIN.CNF Converting to uf2, output size: 131072 Flashing H: (BT817-RP2040-v1.0) 100%|███████████████████████████████████████████████████████████████████████████████| 128/128 [00:00<00:00, 134.74kB/s] Wrote 131072 bytes to H:/NEW.UF2
Hmm, I just got this on the SPI:
Note that CS is not going low. My software is using the exact same pin configuration and working just fine.
What I also noticed is that the eve_flash_pico.uf2 is no longer displaying anything on the screen, the text and the matrix-like animation is no longer displayed. If that is on purpose, ok, why not - but it looks like the backlight still gets activated, please turn it off as well.
By the way, the eve_flash_pico.uf2 does not support updating the blob file yet. I will add this feature later.
It does not? I looked over the sources and it only seems to be using CMD_FLASHUPDATE. And CMD_FLASHUPDATE works fine in flash state BASIC.
I looked over the sources and it only seems to be using CMD_FLASHUPDATE.
Yes, it's reuse EveApps to update blob. Could you try 7b0a3c6? I've just updated the SPI pins configuration to default.
Opening two issues at the same time was probably not the best idea. :-) The new set of uf2conv4eve.py + eve_flash_pico.uf2 does work better now including setting up the pins.
I can flash using this line: python uf2conv4eve.py -p int-7 pwd-6 -f BT817 BT817.blob -i funtype.bin
There still is an issue though. I always have to use that line twice.
PI-PICO USB drive detected at ['H:'] Writing PI-PICO BTEVE program into H: (RPI-RP2) 100%|███████████████████████████████████████████████████████████████████████████████| 152/152 [00:00<00:00, 968.01kB/s] Wrote 147968 bytes to H:/pi-pico-eve-programmer.uf2 BTEVE USB drive detected at 1 ['H:'] No BTEVE drive is detected, existing...
It works on the second call, during flashing the display is active again including the "matrix-effect" style animation. And after flashing there is a reset now with the drive switching back to RPI-RP2.
From uf2conv4eve.py line 344+: if tries == 100: print("Timeout! UF2 is just written but EVE usb drive is not detected") return False else: print("BTEVE USB drive detected at", eve_drives) return True
I added the last line, with this it is working on the first call.
Hi @RudolphRiedel ,
python uf2conv4eve.py -p int-7 pwd-6 -f BT817 BT817.blob -i funtype.bin I always have to use that line twice.
Please try option "-w" to see if it works at the 1st time.
Hi @RudolphRiedel ,
during flashing the display is active again including the "matrix-effect" style animation.
I will hide this animation because it makes other users confuse what's going on. I will replace it with a progress bar and thinking how to detect screen size to make it fit the LCD. May let user input the LCD size as a command argument.
Hi @RudolphRiedel ,
python uf2conv4eve.py -p int-7 pwd-6 -f BT817 BT817.blob -i funtype.bin I always have to use that line twice.
Please try option "-w" to see if it works at the 1st time.
While this should help as the exit point from write_eve_flash_pico() would then be line 318, there is a bug that I fixed on my side, see above.
The output is: BTEVE USB drive detected at['H:'] No BTEVE drive is detected, existing...
This led me to line 344+ and I found that a "return True" line is missing after the print("BTEVE USB drive detected at", eve_drives) line.
Hi @RudolphRiedel ,
during flashing the display is active again including the "matrix-effect" style animation.
I will hide this animation because it makes other users confuse what's going on. I will replace it with a progress bar and thinking how to detect screen size to make it fit the LCD. May let user input the LCD size as a command argument.
I would prefer if the display does not show anything and that the backlight also is disabled. Perhaps implemented as an option. The reason is that the displays need to be powered and that is increasingly difficult from 7" and up.
And I also would apreciate to have a second .uf2 file that is written to the flash of the RP2040 and therefore permanent, manual installation would be fine.
Hi @RudolphRiedel,
- would prefer if the display does not show anything and that the backlight also is disabled.
- to have a second .uf2 file that is written to the flash of the RP2040 and therefore permanent
Applied in 4e91e78
to have a second .uf2 file that is written to the flash of the RP2040 and therefore permanent Applied in https://github.com/Bridgetek/pico-brteve/commit/4e91e780f0dddb847f632e34614f7a7edeb31127
Nice, no complaints from me. :-) I downloaded the branch and I am in the process of testing it.
But, isn't that a bit far for you? My idea was to have a Pi-Pico dedicated to nothing else, connect it to an adapter, preferably apply some electrical isolation and have it ready when I want to flash any BT81x based module. But then you have hardware like the IDM2040-7A and MM2040EV and users of these might prefer a non-permanent solution. I also found it conveniant to test the display with the same Pi-Pico I was flashing the module with, I am only not using RP2040 controllers for anything else than testing since they do not have the hardware units I need.
And as I am still not sure if I even should try a pull-request against a branch and if I can actually fork a branch to try it, since "uf2conv4eve.py" did not change it still is missing a line.
In the repository now:
The version with the additional "return True" I am using now:
Ok, I used my second Pi-Pico and an adapter board and soldered wires between these for a permanent connection.
And it works, but not entirely as expected. I need to supply the "-p int-7 pwd-6" option or it will not flash the image even if the pins are already configured. After flashing the image the Pi-Pico is reset by the application into Boot mode. And when trying to flash another image the .uf2 gets written to the Pi-Pico which makes the persistent application kind of pointless. :-)
So, I guess with regards for boards like the IDM2040-7A and in order to not go deeper into the rabbit hole of changes, it might be a good idea to revert the change of having the application persistent.
This works fine for me now: python uf2conv4eve.py -p int-7 pwd-6 -f BT817 BT817.blob -i Test_Image_2.bin
And what I really should do is to find a way to build the application for the Pi-Pico so that I can change it to whatever I prefer without bothering you with things that you do not actually need. I feel like I should do pull requests and not bug reports, at least for things that qualify as bug fixes.
Hi @RudolphRiedel ,
And what I really should do is to find a way to build the application for the Pi-Pico
Please follow this guideline
Hi @RudolphRiedel,
it might be a good idea to revert the change of having the application persistent
Reverted as your suggest. please check 3d78fa3
Please follow this guideline
I am a bit reluctant to do that and this entirely on my side. I am not at all happy with the RP2040 toolkit for Windows.
Reverted as your suggest. please check https://github.com/Bridgetek/pico-brteve/commit/3d78fa33191bc6405a70ecaab7453fe56ffb0556
I just grabbed uf2conv4eve.py and eve_flash_pico.uf2 from that branch. I had no issue programming the flash image and after a reset my application was running again.
So thank you, I will close the issues now.
I wanted to try out flashing with a Pi-Pico. When I use reset+boot the drive "RPI-RP2" pops up in my Windows 11. When I drag eve_flash_pico.uf2 into that drive it vanishes and does not come back as "BTEVE-FLASH".
USB Device Tree Viewer shows that there is nothing on the USB after using eve_flash_pico.uf2. Using eve_flash_pico.uf2 from EAB 2.8.0 has the same result - the USB port is just dead afterwards. "Connection Status : 0x00 (No device is connected)"
I also used flash_nuke.uf2 to make sure that the content of the flash of my original Pi-Pico is cleared out.