v2.3.5 will not flash or work with the new openxenium 1.4

[tcirre93]

The new version 1.4 of openxenium was recently released and v2.3.5 can no longer recognize this version when trying to update using the upgrade tool. It recognizes the openxenium but fails to read properly during the flash. I tried a manual flash and it did not work either. Looks like a mismatch somewhere.

[catogtp]

Can confirm. I flashed 1.4 cpld code to OX that was using build 2.3.1 of XeniumOS. Run the 2.3.5 updater, it goes through and erases and flashed, but fails when it verifies

[gaasedelen]

I tested this tonight after cato mentioned this issue and was able to reproduce your problem.

I've reflashed bios' a few dozen times on my Xenium since the updated CPLD a few weeks back, so I was curious what XeniumOS does since it seems able to reliably write to flash just fine:

It looks like they specifically try and read-back the byte they just wrote (the while loop) and wait for that to return the correct results. This differs from what this repo, and Xenium-Tools do:

xenium-fw-update/src/main.cpp

Lines 278 to 283 in 1544aff

	for (uint32_t i = 0; i < sizeof(patch_bootloader); i++) {
	xenium_start_flash_program_byte(XENIUM_BANK_BOOTLOADER_OFFSET + i, patch_bootloader[i]);
	while(xenium_flash_busy()) { ;; }
	}

...

xenium-fw-update/src/xenium.cpp

Lines 112 to 117 in 1544aff

	uint8_t xenium_flash_busy(void)
	{
	return xenium_flash_read_byte(0) != xenium_flash_read_byte(0);
	}

I guess, reading back the state of byte 0 does not guarantee the state/availability of all flash sectors?

The fix should ditch the existing busy loop and do something like XeniumOS, instead:

void xenium_start_flash_program_byte(uint32_t address, uint8_t data)
{
    lpc_send_byte(0xAAAA, 0xAA);
    lpc_send_byte(0x5555, 0x55);
    lpc_send_byte(0xAAAA, 0xA0);
    lpc_send_byte(address, data);
    while (xenium_flash_read_byte(address) != data);
}

I tested this on hardware, and it appears to work. I also tested it on even faster chips with less wait states than the recent 1.4 CPLD, so it should be solid fix and seems to make sense:

While Xenium-Tools seemed to be able to read and write ok in its current state (its write loop isn't as tight) it's probably best this fix be reflected over there too. I'll probably make PR's to both repos, and maybe fix up a quirk or two while I am at it.

Here's an updated fw-update xbe with the fixes described above, let me know if this works for you: xenium-fw-update.zip

[tcirre93]

Can confirm this fix works. Everything works as it should!

[Ryzee119]

Just saw this issue and was about to add it to xenium tools. Interesting that fixes it though
The datasheet specifically says you can read any address
Toggle Bit I on DQ6 indicates whether an Embedded Program or Erase algorithm is in progress or complete, or whether the device has entered the Erase Suspend mode. Toggle Bit I may be read at any address

The legacy chip has identical wording
Toggle Bit I on DQ6 indicates whether an Embedded Program or Erase algorithm is in progress or complete, or whether the device entered the Erase Suspend mode. Toggle Bit I may be read at any address,

🤷