Test the build on a real v3 board #7
Comments
|
I can test on v3 hardware. I have a v3.5c, date stamped Sep 2011. Is there a specific test procedure, or are you just making sure it works at all? |
|
I can confirm that the latest firmware builds and runs on the v3.5c that I have. Terminal looks like it is working fine. I do have an issue with I2C that I didn't have in 6.1 which I have been using regularly. When reading a register ( |
|
Hm.. I wonder if the I2C regressions were caused by 3c82068 ? |
|
I can check that tomorrow. I just so happened to be using that when I saw the request for a tester, so it was the first thing I noticed |
|
@CoryHenderson would it be possible to check whether the board also passes selftest and if the hardware information report makes any sense? |
|
@kallisti5 Wasn't 3c82068. Just tried reverting the commit, same results. |
|
@agatti Self test looks good:
By hardware information, do you mean just the
|
|
@CoryHenderson yep, that's all I needed to check - thanks! For I2C, I'll try to get the last revision off DP's repo to build for v3 and MPLAB X later on today, I hope you can give it a spin when you have the time. |
|
@agatti Sounds good. Today will be the last day I have for a few weeks, but I can hopefully start contributing more starting mid September. |
|
@CoryHenderson, here's a build from the tree at DangerousPrototypes@10f1ec1 - disabling enough features (OpenOCD, Basic interpreter, JTAG, PC-AT Keyboard) to fit in the available ROM space. Thanks for the help :) |
|
@kallisti5, do you think it would help to ping Seeed/Sparkfun/Dangerous Prototypes directly and ask for a fully assembled board to support this endeavour? If it's Seeed, I'll be in Shenzhen later this month so I could even pop by and pick it up in person ;) |
|
@agatti v6.3 has the I2C bug as well. I had a version of v6.2 (r1981) laying around from a while back. Tried that, and it works fine. I am attaching text file logs of my I2C read operation from each. As you can see, the version from r1981 has the correct output of 0x8904, which is the device ID of the WM8912 I am reading from. The r2151 build returns 0x89FF |
|
@CoryHenderson great catch! I'll have a go at it this weekend and see what I can get out of it, although I'll have to first rig something up on an ESP8266 or Arduino to have any I2C bus to read from. |
|
@CoryHenderson, can you please give this firmware a try when you have the time in a few weeks? All the DP SVN dumps I found so far stop at r2115 - need to find more recent dumps I guess... |
|
So far, a sniffing between a BMP280 and ESP8266: The debug output via serial: The double read seems ok: |
|
@coelner thanks for the report! Can you please check if using any newer firmware than r2088 trigger the problem on double read? Maybe if you can capture the signals in something I can open with Saleae Logic would also help if double read fails. |
|
I tried this version: BPv3-firmware-v6.3-r2151_by_tayken-spi_fix.hex |
|
@agatti, USBEprom is providing some test reports for BPv3 at DP forum |
|
The scripting engine (BASIC interpreter) is disabled by default on v3, I'll see if I can re-enable it without going out of RAM. However the VREG LED not lighting up is sort of weird - I'll quickly look in the source code to see if anything went wrong when cleaning the selftest module up. However, maybe it'd be helpful if people would post bugs here rather than on different forums, as not everyone has an account on dangerousprototypes' forum :) |
|
The LED issue has been fixed with 10e9ea1 - but for the BASIC interpreter I'm not sure about enabling it by default. Once enabled, v3 has literally 2% of RAM left, which means that the moment we add anything else we have to switch that one off. |
|
For the record, the BASIC interpreter can be enabled here: Bus_Pirate/Firmware/configuration.h Line 306 in 10e9ea1 |
|
@agatti, wow, sure USBEprom will be happy to hear about this. Thank you! |
|
BPv3's bootloader had a troubled history. As you can see in /BPv3-bootloader, there are 5 different bootloaders, and there are different steps to take to upgrade from one version to the other. If you're not using ICD and updating via the serial port, then http://dangerousprototypes.com/blog/2010/01/18/how-to-bus-pirate-bootloader-v4-upgrade/ is what you need to read first - then migrate firmware-v4.1, firmware-v4.3, firmware-v4.5, upgrader-v2tov4, and upgrader-v4tov4 from MPLAB 8 to MPLAB X. Now, from the link on dangerousprototypes.com it seems like the user in question is using bootloader v4.4 - which is not available in source form. Chances are it is v4.5 but the bootloader version was not updated in the source code. Considering the elevated risk of bricking the board and have to resort to ICD, I'd be careful in touching this and just keep the bootloader as it is. Plus, it's written in 100% assembler, so you can crank up the optimisation level as high as you want but nothing will change... |
|
So, v4.4 is in firmware-v4.3. Moreover, here's the diff from v4.3 to v4.5: agatti@tardigrade ~/src/Bus_Pirate/BPv3-bootloader $ diff firmware-v4.3/src/ firmware-v4.5/src
diff --git a/firmware-v4.3/src/ds30loader.s b/firmware-v4.5/src/ds30loader.s
index 19ff413..81809c0 100644
--- a/firmware-v4.3/src/ds30loader.s
+++ b/firmware-v4.5/src/ds30loader.s
@@ -147,7 +147,7 @@
; .equ STARTADDR, ( FLASHSIZE - 2*(PAGESIZE * 2) ) /*place bootloader in 2nd last program page*/
.equ STARTADDR, ( FLASHSIZE - (2* (PAGESIZE)) ) /*place bootloader in last program page*/
.equ BLCHECKST, ( STARTADDR - (ROWSIZE) ) /*precalculate the first row write position that would overwrite the bootloader*/
- .equ BLVERSION, 0x0404 ;bootloader version for Bus Pirate firmware (located at last instruction before flash config words)
+ .equ BLVERSION, 0x0405 ;bootloader version for Bus Pirate firmware (located at last instruction before flash config words)
;------------------------------------------------------------------------------
; Validate user settings
;------------------------------------------------------------------------------
@@ -316,6 +316,8 @@ setup:
rcall Receive
sub #HELLO, W0 ;check
bra z, helloOK ; prompt
+ sub #'#', W0 ;check
+ bra z, exit ; prompt
SendL 'B'
SendL 'L'Whose only difference would be to not wait for commands if 0xE4 is sent as the first character instead of 0xC1. If the user was able to reflash a custom firmware, he's good to go and he's better off leaving that bootloader alone :) |
|
Interesting note about BASIC interpreter: with "s" option it takes just 69% instead of 98% ;) |
|
Hi all. I had a look into this forum but honestly I understood very few things. bpv3_fw7.0_opt0_18092016.hex First I have converted them into uppercase in order to use pirate-loader for the upgrade, then I upgrade my Bus Pirate 3.6 with them all. Writing page 41 row 334, a700...OK Error updating firmware :( Based on explanation of mikebdp2 and of agatti and of others, seems to not be a problem. HiZ>i Bus Pirate v3.5 This time for them all the self test works fine and the VREG led glow. Based on some bugs listed here viewtopic.php?f=28&t=6097, I have digged more deeply. HiZ>b
(9)>10 (34)>8 It works! For what I know up to 255 characters of syntax may be entered into the Bus Pirate terminal at once. I have not an oscilloscope so I can not say if SPI protocol is okay or still has the MOSI problems (viewtopic.php?f=4&t=6667#p58785) fixed by tayken doing correction of typo found by luftek (viewtopic.php?f=4&t=6667&start=15#p59041) I can not test if the i2c timeout problem has been fixed or not (viewtopic.php?f=4&t=8546). Last but not least, the software flashrom_v0.9.9_Win does work! bpv3_fw7.0_opt1_features.hex First I have converted them into uppercase in order to use pirate-loader for the upgrade, then I upgrade my Bus Pirate 3.6 with them all. Writing page 41 row 334, a700...OK Error updating firmware :( Based on explanation of mikebdp2 and of agatti and of others, seems to not be a problem. HiZ>i Bus Pirate v3.5 This time for them all the self test works fine and the VREG led glow. Seems that DIO does not work.
(1)>8 Ready But honestly I do not even understand how test it, sorry. Based on some bugs listed here viewtopic.php?f=28&t=6097, I have digged more deeply. HiZ>b
(9)>10 (34)>8 It works! MACRO(1) and MACRO(2) in 2WIRE protocol they do not work. For what I know up to 255 characters of syntax may be entered into the Bus Pirate terminal at once. I have not an oscilloscope so I can not say if SPI protocol is okay or still has the MOSI problems (viewtopic.php?f=4&t=6667#p58785) fixed by tayken doing correction of typo found by luftek (viewtopic.php?f=4&t=6667&start=15#p59041) I can not test if the i2c timeout problem has been fixed or not (viewtopic.php?f=4&t=8546) Last but not least, the software flashrom_v0.9.9_Win does work! Hoping those are useful. Be seeing you. U.Sb |
|
@USBEprom I limited the buffer size on v3 to 127 characters due to memory constraints when trying to fit as many module as possible: Bus_Pirate/Firmware/configuration.h Line 502 in 10e9ea1 |
|
Hi sir. m
(1)>11 Ready Syntax error at char 3
Repeat, for me it is solved. http://dangerousprototypes.com/forum/viewtopic.php?f=28&t=8498&p=65518#p65518 |
|
Hi guys. Then, out as simple curiosity. |
|
It has been moved to configuration.h (see also https://github.com/BusPirate/Bus_Pirate/blob/master/Firmware/configuration.h#L405). |
|
Thank you sir, I get it now. #ifdef BUSPIRATEV3 I changed the line 405 too in this way #define BP_BASIC_PROGRAM_SPACE 512 in order to make room for BASIC scripting. Finally I changed line 523 from #define BP_COMMAND_BUFFER_SIZE 128 to #define BP_COMMAND_BUFFER_SIZE 256 in order to get up 256 characters for the command line. "F:\MPLABX\XC16\bin\xc16-gcc.exe" ../spi.c -o build/BusPirate_v3/production/_ext/1472/spi.o -c -mcpu=24FJ64GA002 -MMD -MF "build/BusPirate_v3/production/_ext/1472/spi.o.d" -g -omf=elf -DXPRJ_BusPirate_v3=BusPirate_v3 -no-legacy-libc -mlarge-code -mlarge-data -Os -I"../../microchip/include" -I".." -I"../translations" -msmart-io=1 -Werror -Wall -msfr-warn=off -save-temps and the operation fails. Also I know I am boring a lot, but I took a look inside configuration.h and I do not understand where are the messages related to speeds coded into spi.c. |
|
I fixed the build error with 4f44d08, thanks for noticing. If you want to reorder the SPI bus speeds, you have to edit the string files in tools/packstrings/bus_pirate_v?_strings.txt, regenerate the messages_v?.h/messages_v?.s running the python script in tools/packstrings, overwrite the message files in the Firmware directory with what you just generated, then you need to reorder the entries in spi_bus_speed inside Firmware/spi.c. If you want to add more, things get a bit more complicated, and there are limits on how many speeds you can add before breaking the binary serial I/O protocol. |
|
Thank you very much sir, now it work! http://dangerousprototypes.com/forum/viewtopic.php?f=28&t=8498&start=45#p65526 Thanks also for the explanations about what I asked. |
|
@USBEprom can you please create a new issue for this? I'm going to close this one as it is no longer for "test firmware on v3" anymore. |
|
Sorry sir. |
|
Just bought a new BP 3.6. It has Firmware v5.10 preinstalled, but unfortunately it has no JTAG support, so I need to flash a different one. After following a bunch of red herring links wasting almost an hour, I finally managed to find pirate-loader and the 7.0 fw hex files for download. Unfortunately I can't flash the fw. pirate-loader tells me "Checksum does not match, line 4" on every hex file. Converting an hex file to uppercase makes no difference. What am I doing wrong? |
|
@elsni can you please let us know which OS you're using and whether you built the pirate-loader binary yourself from this source code repo or if you're using a pre-built version that came with older firmware packages? |
|
Do you mean also the factory ones by writing "on every hex file"? |
|
Hi, |
|
Hi elsni. http://dangerousprototypes.com/docs/Bus_Pirate#JTAG it said that 6.0 and 6.1 firmwares do contain JTAG terminal mode, hence they have the binary JTAG mode. http://dangerousprototypes.com/docs/Bus_Pirate_firmware_change_history May be you must compile yourself the source in order to build your own firmware. http://dangerousprototypes.com/forum/viewtopic.php?f=4&t=8637#p65660 I do not know if at least one of them allows for JTAG support because I have not seen their configuration setup. |
|
Hey, Hardware: BusPirate v3b pirate-loader.exe from https://github.com/mikebdp2/Bus_Pirate/tree/master/BPv3-bootloader/v4xtov43-bootloader-update/utilities/pirate-loader.exe Firmware Filesbpv3_fw7.0_opt0_18092016.hex I've converted the Firmware Files to uppercase with to_upper.bat to be able to use pirate-loader.exe . Without conversion pirate-loader.exe does not like the Firmware File with lowercase (Checksum does not match, line 4 , Could not load HEX file, result=-1). All Firmware Versions work, besides the bootloader protection error (ERROR [50]). Test Results for all Firmware Versions are the sameWhy does MISO Test fail ? EDIT: Looks like i've damaged the PIC24FJ64GA002 MCU of my BPv3 at my last adventure. MOSI is always HIGH and MISO is always LOW no matter what. |
|
Hi pixeldoc2000. http://dangerousprototypes.com/forum/viewtopic.php?f=4&t=7047 Basically you can test all the pins of your Bus Pirate for short circuit, cold welds or any else fault. |
|
Hi @USBEprom. EDIT: Looks like i've damaged the PIC24FJ64GA002 MCU of my BPv3 at my last adventure. MOSI is always HIGH and MISO is always LOW no matter what. I've bought a BPv4 as a replacement for my broken BPv3 because I really like the BP Conecpt and the new Community Firmware effords. |
|
Update from my testing: I'm only testing the current set of binaries; I don't have time at the moment to get the dev stack installed to build the latest from it. I have the BPv3.6 hardware Each hex ends badly - and identically.
Downgrading to 6.1 works - though it doesn't attempt to write page 42. I haven't updated the boot loader - perhaps that may be involved? |
|
@ ttelford Hi ttelford. http://dangerousprototypes.com/forum/viewtopic.php?f=28&t=8498&start=15 and especially these with careful: http://dangerousprototypes.com/forum/viewtopic.php?f=28&t=8498&start=15#p65317 If something is not wrong ttelford wrote:
It is very old. I guess there is a typo in here. ttelford wrote:
Silicon revision d4 does not exist: http://ww1.microchip.com/downloads/en/DeviceDoc/80000470h.pdf (follow up: http://dangerousprototypes.com/forum/viewtopic.php?f=4&t=8650#p65737) |
Not a typo in either case. It's a direct copy/paste. Still, nice to know The path forward. |
|
@ ttelford About what you wrote "Bootloader version: 1,02", seems it is the ds30 loader version, not your own version of the bootloader. http://dangerousprototypes.com/forum/viewtopic.php?f=4&t=703&p=6862#p6480 About the silicon revision [d4] (Device ID: PIC24FJ64GA002 [d4]) actually you are right, I did not knew it. |
|
Perhaps a bit more about my hardware (and software) is in order: I've been using pirate-loader exclusively, on either Linux or OS X (whichever is close to me a the time...) Does ds30 share code with pirate-loader? I also managed to get a hold of a second, "brand new" (2015 manufacture) Bus Pirate 3.5. Both of my Bus Pirate 3's currently report the following: I'm still seeing the exact same error I reported above with the new firmware images. On a side note: My single Bus Pirate v4 updated to the new release just fine. |
|
@ ttelford The message you wrote ttelford wrote:
is totally right. |
|
Some doubts. #define PGMSIZE 1024 (factory firmware v5.10) = over 3kB (over 700 lines of REM), I do not even know exactly what it actually is, I have not verified precisely. #define PGMSIZE 512 (firmware v7.0 built by myself) = up 511 bytes (exactly 128 lines of REM), not one more. Thanks. |
|
Given that we now have users who are trying the firmware on v3 boards, I guess it's time to retire this ticket. If you have issues related to the community firmware on Bus Pirate v3 boards, please open a new bug if none of the currently open ones match your issue, thank you. This issue has been closed since months, so please open another issue instead of posting here - it makes management easier. |
Now that the firmware can build for v3, it would be nice to know whether it actually works or not. Unfortunately I only have a v4 board here...
The text was updated successfully, but these errors were encountered: