Can't program new TinyFPGA BX ~ 2023-08-22, possibly no metadata?

[eyz]

I just received a new TinyFPGA BX which was ordered through Crowd Supply and shipped by Mouser. I cannot program this new one, but I have an older TinyFPGA BX that programs fine with the same tools.

The power LED is solid red, and the boot LED is pulsing red (during all commands captured below)

Any tips on how to proceed? The messages seem to imply there's a bootloader, but maybe no metadata. Do I need to manually write metadata to the board somehow?

I have many micro-controller boards on hand and in theory could send some SPI commands or similar if needed to resolve this. I believe I have a TinyFPGA programmer as well, if applicable.

$ pip3 list | grep tinyprog
tinyprog                           1.0.21

$ lsusb | grep 1d50
Bus 003 Device 021: ID 1d50:6130 OpenMoko, Inc. 

$ python3 --version
Python 3.10.12

$ tinyprog -p hardware.bin

    TinyProg CLI
    ------------
    Using device id 1d50:6130
    Only one board with active bootloader, using it.
    Programming /dev/ttyACM0 with hardware.bin
Traceback (most recent call last):
  File "/home/isaac/.local/bin/tinyprog", line 8, in <module>
    sys.exit(main())
  File "/home/isaac/.local/lib/python3.10/site-packages/tinyprog/__main__.py", line 334, in main
    addr = fpga.meta.userimage_addr_range()[0]
  File "/home/isaac/.local/lib/python3.10/site-packages/tinyprog/__init__.py", line 182, in userimage_addr_range
    return self._get_addr_range(u"userimage")
  File "/home/isaac/.local/lib/python3.10/site-packages/tinyprog/__init__.py", line 188, in _get_addr_range
    addr_str = self.root[u"bootmeta"][u"addrmap"][name]
TypeError: 'NoneType' object is not subscriptable
make: *** [Makefile:2: upload] Error 1

$ tinyprog -l

    TinyProg CLI
    ------------
    Using device id 1d50:6130
    Only one board with active bootloader, using it.
    Boards with active bootloaders:

        /dev/ttyACM0: No metadata

$ tinyprog -m
Traceback (most recent call last):
  File "/home/isaac/.local/bin/tinyprog", line 8, in <module>
    sys.exit(main())
  File "/home/isaac/.local/lib/python3.10/site-packages/tinyprog/__main__.py", line 257, in main
    m["port"] = str(port)
TypeError: 'NoneType' object does not support item assignment

$ tinyprog --update-bootloader

    TinyProg CLI
    ------------
    Using device id 1d50:6130
    Only one board with active bootloader, using it.
    All connected and active boards are up to date!

[drujensen]

@eyz Confirming that I am running into this same issue. Received this board from Crowd Supply today. If you solve it, would be interested.

looking at the code:

class TinyProg(object):
    def __init__(self, ser, progress=None):
        ...

        # temporary hack, should have better database as well as SFPD reading
        if flash_id[0:2] == [0x9D, 0x60]:
            # ISSI
            self.security_page_bit_offset = 4
            self.security_page_write_cmd = 0x62
            self.security_page_read_cmd = 0x68
            self.security_page_erase_cmd = 0x64

        else:
            # Adesto
            self.security_page_bit_offset = 0
            self.security_page_write_cmd = 0x42
            self.security_page_read_cmd = 0x48
            self.security_page_erase_cmd = 0x44

        self.meta = TinyMeta(self)

Looks like these cmd are not working and meta is returning None. Maybe our boards didn't come with the meta json included?

[eyz]

Looks like these cmd are not working and meta is returning None. Maybe our boards didn't come with the meta json included?

I suspect the bootloader is programmed (because tinyprog indicates it's there) but the metadata file wasn't uploaded. I wonder if it's a known issue for any of the boards produced. I ordered two more and would be overjoyed if they had the metadata on them, so I don't have to figure out how to upload the metadata myself. That said, if it's super easy to connect some SPI up and use an Arduino sketch to upload the metadata I would be up for it.

[eyz]

@tinyfpga is there another TinyFPGA BX production run that includes these metadata files?

[drujensen]

@eyz I did a bit of hacking on the tinyprog project to bypass the meta check. This is only a temporary solution and will break your other fpga's if you do this. You have been warned!

Find where tinyprog source code is at. should be under site-packages and hard code the self.root in the __init__ of the TinyMeta class found in the __init__.py file as follows:

class TinyMeta(object):
    def __init__(self, prog):
        self.prog = prog
        prog.wake()
        self.root = {
            "boardmeta": {
                "hver": "0.0.0",
                "name": "TinyFPGA BX",
                "fpga": "ICE40LP8K-cm81",
                "uuid": "4a300a6f-895a-44d3-b021-356c6b38b339",
            },
            "bootmeta": {
                "bver": "2.0.0",
                "bootloader": "TinyFPGA USB Bootloader",
                "update": "https://tinyfpga.com/update/tinyfpga-bx",
                "addrmap": {
                    "bootloader": "0x00000-0x28000",
                    "userimage":  "0x28000-0x50000",
                    "userdata":   "0x50000-0xFC000",
                    "desc.tgz":   "0xFC000-0xFFFFF"
                }
            }
        }

If you want to be extra safe, copy or fork the project somewhere and then run this python script directly instead of using the one in the path. (Note: I generated a UUID to avoid conflicts)

[eyz]

@eyz I did a bit of hacking on the tinyprog project to bypass the meta check.

Nice! It looks like you are simply hard-coding the expected metadata where it would normally be retrieved from the Tiny FPGA BX. Since I'm only using this one FPGA with tinyprog that's a completely acceptable solution. Great hack! If the USB ID is specific to the tiny FPGA BX maybe this could be a suitable workaround for others as well, such as if that USB ID is found it would simply drop this in if it couldn't be located, like a "use default metadata" flag.

In my case, I found the file you patched in ~/.local/lib/python3.10/site-packages/tinyprog/init.py (for my user install) and /usr/local/lib/python3.10/dist-packages/tinyprog/init.py (for an old root install) on my Ubuntu 22.04.3 system -

class TinyMeta(object):
    def __init__(self, prog):
        self.prog = prog
        prog.wake()
#        self.root = self._read_metadata()
        self.root = {
            "boardmeta": {
                "hver": "0.0.0",
                "name": "TinyFPGA BX",
                "fpga": "ICE40LP8K-cm81",
                "uuid": "4a300a6f-895a-44d3-b021-356c6b38b339",
            },
            "bootmeta": {
                "bver": "2.0.0",
                "bootloader": "TinyFPGA USB Bootloader",
                "update": "https://tinyfpga.com/update/tinyfpga-bx",
                "addrmap": {
                    "bootloader": "0x00000-0x28000",
                    "userimage":  "0x28000-0x50000",
                    "userdata":   "0x50000-0xFC000",
                    "desc.tgz":   "0xFC000-0xFFFFF"
                }
            }
        }

Great idea! Thanks!

$ tinyprog -p hardware.bin

    TinyProg CLI
    ------------
    Using device id 1d50:6130
    Only one board with active bootloader, using it.
    Programming /dev/ttyACM0 with hardware.bin
    Programming at addr 028000
    Waking up SPI flash
    135100 bytes to program
    Erasing: 100%|█████████████████████████████████████████████████████████████| 135k/135k [00:00<00:00, 358kB/s]
    Writing: 100%|█████████████████████████████████████████████████████████████| 135k/135k [00:00<00:00, 229kB/s]
    Reading: 100%|█████████████████████████████████████████████████████████████| 135k/135k [00:00<00:00, 458kB/s]
    Success!

A solid red light is a good red light (flashed successfully, thus solid red now) -

[eyz]

See https://github.com/tinyfpga/TinyFPGA-Bootloader#fpga-board-metadata for some context on the following if you want to dig in.

Security page dumps from an older TinyFPGA BX board

I was successfully able to dump security pages 1, 2, and 3 to binary files from my older model TinyFPGA BX. However, when I tried to program them onto my new TinyFPGA BX (where they are blank, all default flash 0xFF) I saw no evidence of the security pages being updated, presumably because they are write-protected. I suspect there is some process to unlock the write-protection outside of tinyprog. Without this information I believe I cannot proceed further in correcting the security page metadata.

What I modified to dump out the security pages from a TinyFPGA BX that is about 3 years old -

    def read_security_register_page(self, page):
        data = self.cmd(self.security_page_read_cmd, addr=page << (8 + self.security_page_bit_offset), data=b'\x00', read_len=255) # Isaac debug
        print("read_security_register_page", page, data) # Isaac debug
        with open("tinyfpga-bx-security-page." + str(page), "wb") as security_page_file: # Isaac debug
          security_page_file.write(data) # Isaac debug
        return data # Isaac debug
        #return self.cmd(self.security_page_read_cmd, addr=page << (8 + self.security_page_bit_offset), data=b'\x00', read_len=255)

Dumped security pages resulted in -

$ xxd tinyfpga-bx-security-page.1
00000000: 7b22 626f 6172 646d 6574 6122 3a7b 226e  {"boardmeta":{"n
00000010: 616d 6522 3a22 5469 6e79 4650 4741 2042  ame":"TinyFPGA B
00000020: 5822 2c22 6670 6761 223a 2269 6365 3430  X","fpga":"ice40
00000030: 6c70 386b 2d63 6d38 3122 2c22 6876 6572  lp8k-cm81","hver
00000040: 223a 2231 2e30 2e30 222c 2275 7569 6422  ":"1.0.0","uuid"
00000050: 3a22 3863 3934 3263 6136 2d36 6133 662d  :"8c942ca6-6a3f-
00000060: 3439 6537 2d39 3637 302d 6637 6462 3465  49e7-9670-f7db4e
00000070: 3462 3236 3736 227d 7d00 2020 2020 2020  4b2676"}}.      
00000080: 2020 2020 2020 2020 2020 2020 2020 2020                  
00000090: 2020 2020 2020 2020 2020 2020 2020 2020                  
000000a0: 2020 2020 2020 2020 2020 2020 2020 2020                  
000000b0: 2020 2020 2020 2020 2020 2020 2020 2020                  
000000c0: 2020 2020 2020 2020 2020 2020 2020 2020                  
000000d0: 2020 2020 2020 2020 2020 2020 2020 2020                  
000000e0: 2020 2020 2020 2020 2020 2020 2020 2020                  
000000f0: 2020 2020 2020 2020 2020 2020 2020 20   

$ xxd tinyfpga-bx-security-page.2
00000000: 7b22 626f 6f74 6d65 7461 223a 7b22 626f  {"bootmeta":{"bo
00000010: 6f74 6c6f 6164 6572 223a 2254 696e 7946  otloader":"TinyF
00000020: 5047 4120 5553 4220 426f 6f74 6c6f 6164  PGA USB Bootload
00000030: 6572 222c 2262 7665 7222 3a22 312e 302e  er","bver":"1.0.
00000040: 3122 2c22 7570 6461 7465 223a 2268 7474  1","update":"htt
00000050: 7073 3a2f 2f74 696e 7966 7067 612e 636f  ps://tinyfpga.co
00000060: 6d2f 7570 6461 7465 2f74 696e 7966 7067  m/update/tinyfpg
00000070: 612d 6278 222c 2261 6464 726d 6170 223a  a-bx","addrmap":
00000080: 7b22 626f 6f74 6c6f 6164 6572 223a 2230  {"bootloader":"0
00000090: 7830 3030 6130 2d30 7832 3830 3030 222c  x000a0-0x28000",
000000a0: 2275 7365 7269 6d61 6765 223a 2230 7832  "userimage":"0x2
000000b0: 3830 3030 2d30 7835 3030 3030 222c 2275  8000-0x50000","u
000000c0: 7365 7264 6174 6122 3a22 3078 3530 3030  serdata":"0x5000
000000d0: 302d 3078 3130 3030 3030 227d 7d7d 0020  0-0x100000"}}}. 
000000e0: 2020 2020 2020 2020 2020 2020 2020 2020                  
000000f0: 2020 2020 2020 2020 2020 2020 2020 20  

$ xxd tinyfpga-bx-security-page.3
00000000: ffff ffff ffff ffff ffff ffff ffff ffff  ................
00000010: ffff ffff ffff ffff ffff ffff ffff ffff  ................
00000020: ffff ffff ffff ffff ffff ffff ffff ffff  ................
00000030: ffff ffff ffff ffff ffff ffff ffff ffff  ................
00000040: ffff ffff ffff ffff ffff ffff ffff ffff  ................
00000050: ffff ffff ffff ffff ffff ffff ffff ffff  ................
00000060: ffff ffff ffff ffff ffff ffff ffff ffff  ................
00000070: ffff ffff ffff ffff ffff ffff ffff ffff  ................
00000080: ffff ffff ffff ffff ffff ffff ffff ffff  ................
00000090: ffff ffff ffff ffff ffff ffff ffff ffff  ................
000000a0: ffff ffff ffff ffff ffff ffff ffff ffff  ................
000000b0: ffff ffff ffff ffff ffff ffff ffff ffff  ................
000000c0: ffff ffff ffff ffff ffff ffff ffff ffff  ................
000000d0: ffff ffff ffff ffff ffff ffff ffff ffff  ................
000000e0: ffff ffff ffff ffff ffff ffff ffff ffff  ................
000000f0: ffff ffff ffff ffff ffff ffff ffff ff    ...............

Security pages likely are write-protected, otherwise this could work to update them

I tried reading back the binary dumps (above) and update the security pages on the newer board using this function, but no luck (probably due to write protection?) -

    def program_security_register_page(self, page, data):
        self.write_enable()
        self.cmd(self.security_page_write_cmd, page << (8 + self.security_page_bit_offset), data)
        self.wait_while_busy() 

^ I did not include the wrapper that calls this to attempt to re-program each security page, as it wasn't successful. This function is included in this GitHub comment for context only.

No differences once flashed between old and new boards in pages outside of security page area

I also compared my older board with the newer board with the same user bit-stream flashed, and I only saw a difference between the security pages, not the rest of the pages being read during programming, as confirmed by outputting the raw bytes in the rest of the read function calls -

   def read(self, addr, length, disable_progress=True):
        data = b''
        with tqdm(desc="    Reading", unit="B", unit_scale=True, total=length, disable=disable_progress) as pbar:
            while length > 0:
                read_length = min(255, length)
                data += self.cmd(0x0b, addr, b'\x00', read_len=read_length)
                self.progress(read_length)
                addr += read_length
                length -= read_length
                pbar.update(read_length)
            #print("read",addr,length,data) # Isaac debug
            return data

Physical write-protection investigation

From https://github.com/tinyfpga/TinyFPGA-BX/blob/master/board/TinyFPGA-BX-Schematic.pdf, perhaps this needs to be brought high to allow the security pages to be written? -

Datasheet for the AT25SF081-SSHD-B SPI flash at https://www.mouser.com/datasheet/2/698/DIAL_S_A0012368008_1-2956400.pdf helps confirm -

[Blackninja543]

@eyz According to https://github.com/tinyfpga/TinyFPGA-BX/blob/master/TinyFPGA%20BX%20Card%20Back.png pin 10 (H4|spi_io2|SPI Flash WP_B/IO2) looks like it might also be the same write protect pin.

[eyz]

@eyz According to https://github.com/tinyfpga/TinyFPGA-BX/blob/master/TinyFPGA%20BX%20Card%20Back.png pin 10 (H4|spi_io2|SPI Flash WP_B/IO2) looks like it might also be the same write protect pin.

^ It looks like that net (circled in green) is pulled-up to 3.3 volts (circled in purple).

In addition to the labeled circular WP pad on the back, it looks like solder pad # 27 on the back is the same net.

Regarding the mention of pin 10 I think they mean labeled pad # 27, not the outside through-hole pin 10 on the edge of the board, see -

The datasheet states that the WP signal is active low, so I'd assume the pull-up means it's not hardware write-protected. Perhaps another layer of protection is preventing the security page area from being programmed -

At this point, I believe the security register lock bits have likely been set, which appears to permanently (one-time program) set the values in those pages, see -

Given this, I suspect those security page areas with the metadata may not be possible to change, even though the WP net is being pulled up high (which would otherwise disable the hardware write protection on the SPI flash chip)

Here are the security lock registers (LB3-LB1) -

[Blackninja543]

After doing some more research it does appear the fix is going to be a little harder.

SPI Flash Security Register Page 1 (write-protected) One of the SPI flash security register pages contains fixed data about the board that does not change. This is the name of the board, the hardware revision of the board, and serial number unique to the board name. This security register page should be write protected as it should never be changed. If the rest of the SPI flash is erased, this minimal amount of information will help the user to find recovery instructions.

https://github.com/tinyfpga/TinyFPGA-Bootloader

[eyz]

After doing some more research it does appear the fix is going to be a little harder.

SPI Flash Security Register Page 1 (write-protected) One of the SPI flash security register pages contains fixed data about the board that does not change. This is the name of the board, the hardware revision of the board, and serial number unique to the board name. This security register page should be write protected as it should never be changed. If the rest of the SPI flash is erased, this minimal amount of information will help the user to find recovery instructions.

https://github.com/tinyfpga/TinyFPGA-Bootloader

Yep. I saw that at the end of yesterday, prior to my deep dive research today in this comment / thread. I'm now deferring to those here to come up with a solution, or possibly return these units for replacements that are programmed properly. I'm only using the BX personally, so I'm fine leaving that workaround in my tool chain for the foreseeable future, although the proper solution is certainly having the metadata stored properly on the physical hardware.

@tinyfpga ?

[scm2000]

I edited the init method as suggested and was able to program my board, but is there a way that I can program the needed metadata onto the board myself?

[eyz]

I edited the init method as suggested and was able to program my board, but is there a way that I can program the needed metadata onto the board myself?

Based on my extensive research in the thread above, it's extremely unlikely that you can program the metadata into the security protected portion of the SPI flash. My finding was that it's most likely locked when they program the firmware on the board as part of their programming workflow, and effectively read only in that area, thus you can't update it again.

[drujensen]

Should hack a solution in this driver to handle the broken boards?

Maybe something like: if the query to the metadata fails, use this default json file.

[scm2000]

Should hack a solution in this driver to handle the broken boards?

Maybe something like: if the query to the metadata fails, use this default json file.

Right now this is the only board I'm working with... At some point if this isn't fixed in some way officially, I expect I'll do exactly that, --- if it can't get metadata, substitute in this metadata... quite a hack though. but the state of the software is already such that I have to hack around anyway to get apio and tinyprog to work on a mac.

[eyz]

Should hack a solution in this driver to handle the broken boards? Maybe something like: if the query to the metadata fails, use this default json file.

Right now this is the only board I'm working with... At some point if this isn't fixed in some way officially, I expect I'll do exactly that, --- if it can't get metadata, substitute in this metadata... quite a hack though. but the state of the software is already such that I have to hack around anyway to get apio and tinyprog to work on a mac.

It's really only a hack for the toolset that integrates between the metadata in the secure part of the flash and tinyprog though. It was clearly a design decision, and this is where it breaks down in case the secure area gets locked on the flash unusable. Patching the software side is not horrible considering it can potentially be corrected if the manufacturer acknowledges the issue, and I'm fine if that is via any form of communication we can see here.

I just got two more from Mouser a few days ago and I'll report back if they have the same issue, or if this batch I received it seems to be resolved.

[Blackninja543]

I believe the only true fix to this issue is to de-solder the the flash, reprogram it, and solder it back in place.

[eyz]

I believe the only true fix to this issue is to de-solder the the flash, reprogram it, and solder it back in place.

If the flash security section is locked, then yes- that's the only solution that I'm aware of. Patching the software toolchain is way easier though, so unless you are really fond of working on boards (for fun?) and you also need to use a certified / checksum-verified toolchain from the original release, I don't recommend replacing the flash.

[drujensen]

https://github.com/tinyfpga/TinyFPGA-Bootloader/pull/73

[jeffpc]

I don't know anywhere near enough about USB, but it sounds like there are possibly different levels of problems with the latest batch of BX boards. (I got one via Mouser.) Mine, for example, fails to complete the USB initialization with the host, and so the host doesn't even get far enough to present a usable device for tinyprog to use.

I filed a bug about it: https://github.com/tinyfpga/TinyFPGA-Bootloader/issues/74

[richgel999]

I'm getting the "No metadata" error too. Bummed out.

[richgel999]

Should hack a solution in this driver to handle the broken boards?

Maybe something like: if the query to the metadata fails, use this default json file.

Yes, please. I'm a FPGA beginner, and it looks like I can't use this TinyFPGA BX board without hacking some source files. Thanks!

[richgel999]

Even after getting my TinyFPGA BX from Crowd Supply to program (by working around the no metadata bug), I noticed the 3v3 pin is actually 5v. This explains why the LED's are so insanely bright. The 3v3 regulator is not functional.

If I can't even program it out of the box without hacking the programming software, something is wrong. How was this ever shipped?

[aacuevas]

The company I work for has had this problem. Apart for the issues with the LDO, it seems that the AT25SF081 memory piece has been replaced by a revision AT25SF081B This B part is 99% the same as the original, EXCEPT, the addresses for security pages are shifted 4 bits. The annoying part is that the DeviceID for that flash part is the same, so there is no automated way, at least no easy (and documented) one to tell the devices apart.

I made a branch of the tinyprog repo which includes an --atb switch to account for this discrepancy. It is nasty hack, but works until someone can find a way to automate this process. (There seems to be a SFDP record that is different from the original model, so maybe we could use that)

Now, while it is true that security page 1 is locked from factory in these devices, it is possible to write the metadata that should be in page 1 in page 2, and the metadata for page 2 in page 3. Page 3 is usually empty, so this should suffice to enable the boards to be used.

So, to program the security pages you can use the attached files (basically, extracted from an older batch tinyfpga) and use my forked tinyprog with the commands tinyprog --atb --security page1.txt -a 2 tinyprog --atb --security page2.txt -a 3

And then the --atb switch to program, to let the script to know it has to read metadata from these modified addresses tinyprog --atb -p your_bitfile.bin

These seem to have worked for us.

Note: The page1 metadata includes an uuid that should be unique per board. I strongly encourage writing a new one per board. This simple online generator should generate random ones.

page1.txt page2.txt

[psychogenic]

This is great, Aarón: just tried your patch, and it worked: thanks! I patched it a bit further (PR issued--I wanted to be able to use all my BX using the same commands, so the -atb can be dropped once the fix is applied to a board).

[aacuevas]

Cool! This is a nice patch, as at least normal operation can be done as normally. Thanks!

I think some automation should still be possible to tell chips apart and not require the --atb flag at all. It's annoying that they did not update the DeviceID command, which is for this case specifically. Bur probably the SFPD records can be used for this, even if it's in a very naïve and hacky way,

[jonathancollins514]

hi @aacuevas ,

THanks for all of this, is there a place to download the final exe of the programmer? Can you also elaborate more on the LDO issue making the led blinding and if it can also be fixed.

ok found the this for the LDO will try it out: https://github.com/tinyfpga/TinyFPGA-BX/issues/39

But question about a compiled exe for the programmer still reamin as not yet to familiar with python stuff

[eyz]

Did anyone get a board without this issue? If so, when did you order it, and when did you receive it?

[AaronJackson]

Did anyone get a board without this issue? If so, when did you order it, and when did you receive it?

I've also got this issue - came through in the latest Crowdsupply batch, received a week or two ago. Tried emailing tinyfpga but not heard anything back.

[maydaym3]

Received two BX boards from Mouser late August 2023 and just now getting to them, both have no metadata issue

[eyz]

Received two BX boards from Mouser late August 2023 and just now getting to them, both have no metadata issue

That's great news. Also, can you confirm the voltage on the 3.3 volt and 5 volt rails? I think that was the only other concern. Additionally, if you have any markings from the metadata or physically please let us know the batch numbers or whatever you can applicable from your builds.

[maydaym3]

Received two BX boards from Mouser late August 2023 and just now getting to them, both have no metadata issue

That's great news. Also, can you confirm the voltage on the 3.3 volt and 5 volt rails? I think that was the only other concern. Additionally, if you have any markings from the metadata or physically please let us know the batch numbers or whatever you can applicable from your builds.

sorry 'No Metadata' issue

TinyProg CLI
    ------------
    Using device id 1d50:6130
    Only one board with active bootloader, using it.
    Boards with active bootloaders:

        /dev/ttyACM1: No metadata

[arndgo]

Hi Aarón, thanks a lot for figuring that out. Your solution is working perfectly. To be honest, it was hard for me, to get a running tinyprog.exe program out of the code. This is mostly related to my missing knowledge about Python and the tool chain. But finally I made it. One small thing about your changes. At line 333 you added: print("Can't find meta--attempting Adesto B patch") That's nice for information, but if you are using e.g. Icestudio, this 'information' is an issue for the FPGA tool chain. Not a big deal, as you can program the FPGA manual via command line. For test reason, I out-commented this line, and the programming out of Icestudio is also possible without any issues.

I'm a little bit disappointed about Crowd Supply, that there is no patch or notice about the issue(s) with some of the modules... It's 8 month now, and no official reaction :-(

Many thanks again Aarón for your patch. Perfect work....

[taylor-hartman]

@AaronJackson Just ran into this issue as well, but unfortunately i seem to not be able to get to work with your fork/hack.

I'm getting:

TypeError: ord() expected a character, but string of length 0 found

Whenever I try to write security page 3, or a .bin.

Any guidance is much appreciated.

[AaronJackson]

@taylor-hartman there are two Aarons in this thread, think you mean @aacuevas

I am useless and a newb and gave up as soon as I ran into the issue. Maybe I'll try again eventually but so far it was a waste of $60 :sob:

[scm2000]

@taylor-hartman there are two Aarons in this thread, think you mean @aacuevas

I am useless and a newb and gave up as soon as I ran into the issue. Maybe I'll try again eventually but so far it was a waste of $60 😭

I'll withhold my opinion of this situation and just say if you follow this thread carefully, you will have a good chance of getting your board working. If not it's a 60 dollar lesson you've learned.

[eyz]

Sure feels like we're on our own. Who's going to fork this and fix the remaining issues, and start a new board run?

[Bexin3]

Unable to upload here too, system report doesn't see the board, quite disappointing there was never a statement on this and crowdsource keeps selling them

[maydaym3]

i am currently working on a pi pico uf2 that will be able to reprog the spi flash. to be able to be recognized by tinyprog. it will require either a soic8 programmer clip or some minor soldering to work. more to come in the next week/month.

also, my boards came with the 5v0 LDO instead of the 3V3.... SMH. i dont even want to see what the EX board is going to be like...

[Bexin3]

i am currently working on a pi pico uf2 that will be able to reprog the spi flash. to be able to be recognized by tinyprog. it will require either a soic8 programmer clip or some minor soldering to work. more to come in the next week/month.

also, my boards came with the 5v0 LDO instead of the 3V3.... SMH. i dont even want to see what the EX board is going to be like...

Quite unfortunate, to be honest I am tempted to just returning this and trying the new batch as it seems like a solid bit of effort. But then who knows if the new batch will be any better I fixed the LDO issue by using scissors as I didn't have a soldering pin but the rest doesn't work and well, I sadly don't have the said programmer so I'll hold out a bit more if there is another fix. Also interestingly for me while the computer sees it tinyprog doesn't

[Bexin3]

I have now tried this in windows and the errors are different though I am confused about the cause

PS C:\Users\Bexin\Downloads\tinyfpga\tinyfpga> tinyprog -p test-tiny.bin

    TinyProg CLI
    ------------
    Using device id 1d50:6130
    Only one board with active bootloader, using it.
    Programming COM4 with test-tiny.bin
Traceback (most recent call last):
  File "<frozen runpy>", line 198, in _run_module_as_main
  File "<frozen runpy>", line 88, in _run_code
  File "C:\Users\Bexin\AppData\Local\Programs\Python\Python312\Scripts\tinyprog.exe\__main__.py", line 7, in <module>
  File "C:\Users\Bexin\AppData\Local\Programs\Python\Python312\Lib\site-packages\tinyprog\__main__.py", line 334, in main
    addr = fpga.meta.userimage_addr_range()[0]
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Users\Bexin\AppData\Local\Programs\Python\Python312\Lib\site-packages\tinyprog\__init__.py", line 182, in userimage_addr_range
    return self._get_addr_range(u"userimage")
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Users\Bexin\AppData\Local\Programs\Python\Python312\Lib\site-packages\tinyprog\__init__.py", line 188, in _get_addr_range
    addr_str = self.root[u"bootmeta"][u"addrmap"][name]
               ~~~~~~~~~^^^^^^^^^^^^^
TypeError: 'NoneType' object is not subscriptable

[eyz]

Would anyone be up for a full PCBA (gerber and BOM file) project export for these with one or more common PCBA vendors, including any recent passive swap-outs and zero firmware flashing? I think we need to take this over, because there have been no updates from the original project owner on this for some time, and power regulator and PROM flashing have had problems, as documented in this GitHub issue

[eyz]

Let's try to ensure the next round of boards won't have 5V on the 3.3V pin (https://github.com/tinyfpga/TinyFPGA-BX/issues/39#issuecomment-2386551707) due to a AP2210K-3.3 part swap having pin 4 wired, and hasn't written zeros to the area of the PROM on the FPGA where metadata needs to exist to allow tinyprog to identify the board (https://github.com/tinyfpga/TinyFPGA-BX/issues/37#issuecomment-1694056732).

Per Mouser, there is a batch expected out around May 2025. If these are also botched, let's try and get PCBA files to produce these instead.

If anyone has a contact for who is producing the next run, could you please reach out to them and let them know of these two critical issues? A Mouser contact here who is on Github would also be appreciated to share the findings.

[Bexin3]

Let's try to ensure the next round of boards won't have 5V on the 3.3V pin (https://github.com/tinyfpga/TinyFPGA-BX/issues/39#issuecomment-2386551707) due to a AP2210K-3.3 part swap having pin 4 wired, and hasn't written zeros to the area of the PROM on the FPGA where metadata needs to exist to allow tinyprog to identify the board (https://github.com/tinyfpga/TinyFPGA-BX/issues/37#issuecomment-1694056732).

Per Mouser, there is a batch expected out around May 2025. If these are also botched, let's try and get PCBA files to produce these instead.

If anyone has a contact for who is producing the next run, could you please reach out to them and let them know of these two critical issues? A Mouser contact here who is on Github would also be appreciated to share the findings.

I believe the flash overwriting thing only happened to some people, as it worked for me after cutting off the extra pin to make it 3.3v, as well as some others, so it's worth trying. That said I really hope the same issue won't be on the next batch, definitely needs to get looked into.

[eyz]

I believe the flash overwriting thing only happened to some people, as it worked for me after cutting off the extra pin to make it 3.3v, as well as some others, so it's worth trying. That said I really hope the same issue won't be on the next batch, definitely needs to get looked into.

Maybe these were two different events that could have overlapped, with some of the 5V on 3.3V pin boards not having been one-time programmed with incorrect metadata; perhaps there were multiple production runs with different conditions. Thanks for the insight