Remora on NVEM board - unable to upload new configs

I managed to get Remora uploaded to an NVEM v5 board, thanks to Scott's detailed video instructions. The board has the RT1052 chip and I was able to make a donor STLink into a DAPLink and upload the firmware by compiling the latest Remora-RT1052-cpp source. I could see it working by toggling the eStop in software and seeing the LED light up on the board so I know it was responding to LinuxCNC. Just like in the video. 

I then successfully uploaded the full_config.txt with the upload_config.py script, I managed to get past needing to install the TFTP package via PIP successfully. I did manage to get the config file (the supplied unmodified config) uploaded to the board the first time but now I'm trying to make updates to the config and it no longer uploads. The script confirms it's valid config, but now I get a time-out error. I can still ping the device and get responses, something else is blocking it. 

I've already de-soldered the pin headers - and packed away all of my soldering gear. I could re-solder it and re-flash with a fresh firmware, but ideally would like to avoid that in case this happens again.

Seems the board is now bricked and won't accept new configs. The LED eStop indicator on the PCB is lit permanently and I can no longer toggle it in software.

Any ideas how I can get this up and running again? I've tried to be as specific as possible. I'd love to share some screengrabs and stuff, but the system is set up offline in another room. Let me know what I can provide to troubleshoot? I can get the computer connected to the internet to share configs and logs and other bits and pieces if that helps. Just thought maybe someone knows an obvious answer?  

forum.linuxcnc.org/18-computer/44828-rem...cnc-board?start=2080

take it to here,

but if flashing the config worked before and now it wont work, you will probably need to do a full chip erase to overwrite the sector, then reload the firmware and config.

Thanks! will do.

Hi,

Thanks for sharing your experience - I'm running into a very similar issue and hoping you might have found a solution since posting this.

I'm using an NVEM V5 board (RT1052 chip). I successfully flashed the firmware via pyOCD (tried multiple firmware versions: remora-rt1052-NVEM-0.2.1.bin, remora-rt1052-0.0.1.bin, remora-rt1052.bin - all flashed without errors). Ping to 10.10.10.10 works perfectly and consistently.

However, unlike your case, I'm getting a timeout on my very first config upload attempt - not after a successful first upload. I've tried:
- My own custom config file
- The unmodified official example configs (both nvem-rt1052.txt and remora-rt1052-basic/ec500-rt1052.txt)
- Uploading with the SWD/ST-Link connection both attached and disconnected during the upload
- Confirmed via tcpdump that the WRQ packet is sent correctly on port 69, but no response ever comes back from the board
- No firewall involved (iptables set to ACCEPT), direct point-to-point Ethernet connection, no router

The script always confirms "Valid JSON config file" and calculates the CRC correctly, so it gets stuck at exactly the same point you describe - after everything on the PC side looks fine.

Did you ever find out what caused the board to stop responding to TFTP? Was it possibly related to the eStop/enable state getting stuck, as you mentioned the LED stayed permanently lit? Any insight into how you (or anyone else) resolved this would be hugely appreciated - trying to avoid unnecessary re-flashing if there's a known cause.

Thanks in advance!

Okay, sorry

Additional update: I ran a UDP port scan to check the TFTP service status directly:

sudo nmap -sU -p 69 10.10.10.10

Result:
PORT STATE SERVICE
69/udp closed tftp

This is significant - "closed" (not "open|filtered", which is the typical ambiguous UDP result) means the board actively responds with an ICMP port-unreachable message. This confirms the TFTP service itself is never bound/listening on port 69 at all - it's not just that requests go unanswered on an otherwise-open port.

I also looked through remora-rt1052.cpp and noticed the TFTP server is initialized via:
IAP_tftpd_init(dmaThread->DMAptr->EDMA_Handle);
in the ST_SETUP state, right after loadModules(). This suggests the TFTP server initialization may never complete successfully during startup - which would explain why port 69 shows as actively closed rather than just non-responsive.

I've now tested every available NVEM-specific firmware (only remora-rt1052-NVEM-0.2.1.bin exists in the Remora-RT1052 repo) as well as the generic 3.1.x versions from Remora-RT1052-cpp (which don't even respond to ping on this NVEM V5 board, matching what "disneysw" reported earlier in this thread). I'm at the limit of what I can diagnose from the outside - any insight into the TFTP server startup sequence would be much appreciated.

SOLVED — root cause: NVEM V5 (at least this clone/revision) has only 2MB of flash, but Remora-RT1052-cpp stores the config at an address beyond that

For anyone hitting the same wall I did — board pings fine with the old firmware but never responds at all (no ping, no ARP, nothing) with any of the newer Remora-RT1052-cpp builds (2.1.1, 3.1.x) — here's what was actually going on, at least on my board.

Board: NVEM V5 clone, silkscreen "1NKR_NVEM_V6", MIMXRT1052CVL5B

The flash chip on my board is a Winbond W25Q16JVSIQ. "16" = 16 Mbit = 2MB. The firmware, however, defines JSON_STORAGE_ADDRESS in source/configuration.h as:

#define JSON_STORAGE_ADDRESS 0x00200000 // beginning of Block 32

0x00200000 is exactly 2MB — i.e. one byte past the end of a 2MB chip. On boot, once the firmware reaches jsonFromFlash() and tries to read the length word at that address, it hard-faults silently (the hard fault handler in this firmware only catches semihosting breakpoints, so a genuine fault just hangs with zero console output). This happens before the main loop ever gets around to servicing the Ethernet/lwIP stack, which is why nothing ever answers on the wire — no ARP, no ICMP, nothing. It looks exactly like a dead ENET/PHY, but it isn't.

How I confirmed it:
- Got a debug UART connection going (LPUART4, 115200 8N1, pins GPIO_B1_00/B1_01 — on my board these come out on connector P6, which is also wired to a MAX3232 for RS232 levels, pins 2/3, pin 1 GND)
- Boot log stopped dead right after "1. Loading JSON configuration file from Flash memory" — no "Flash storage location is empty" message, no crash message, just silence
- Older firmware (0.2.1, no TFTP, config hardcoded) never touches this address at all and boots/pings fine every time — same hardware, same cable, same everything else
- Confirmed the JSON_UPLOAD_ADDRESS (0x001F0000, "Block 31") is already the last valid block on a 2MB chip — Block 32 simply doesn't exist on this flash

Fix: moved JSON_STORAGE_ADDRESS to an address safely within the 2MB range and clear of both the app code and the upload staging area:

#define JSON_STORAGE_ADDRESS 0x001E0000 // Block 30

Rebuilt with MCUXpresso (had to set up the toolchain from scratch, straightforward once the SDK pulls in), reflashed, and the board now boots all the way through — PHY init, JSON load (correctly falls back to default config when flash is empty), full module setup, IDLE state — and pings/TFTP-uploads immediately. Config upload via upload_config.py now works exactly as expected.

Worth checking your own flash chip's part number before assuming it's a hardware/ENET/PHY problem if you're seeing total silence on the network with the C++ firmware — a 2MB chip on these clone boards looks to be common enough that others may be hitting exactly this.

Happy to share the exact board.c / configuration.h diffs if useful.