Remora - ethernet NVEM / EC300 / EC500 cnc board

Capper wrote:

yes, i am using the NVEM-basic-configuration from youre github. As you mentioned, my plan was to take this as an example for further adjustments.

That error occures every time the software tryes to move the Motors (not only while jogging). After that error i have to reinitiate the machine.

By turning down the feedspeed to ~0.9mm/min, i could observe that the pos_cmd seems to count up until it reaches the FERROR-value from the config.

My setup constist out of the NVEM with one Stepperdriver (DM422 without feedback) attached to the x-axis. Endstops and other stuff are detached.
Instead of an raspberry i am running an Desktop-PC with the Linuxcnc-Debian10 (Buster) version you can find here in the forum.

could it be possible, that the communication between NVEM and linuxcnc has any problems? I had to set the static IP via "/etc/network/interfaces" instead of the "etc/dhcpcd.conf", like you've done in the video.

if there are any logs needed, just let me know.

Edit:


This board is about 4 Years old btw. There are clearly differences in the layout between yours and mine.

Don't think this really matters but who knows.

Also, i have to withdraw my statement, where I've said the inputs can be observed. Checked it and it's not the case.

So, after uploading the Basic-configuration.txt (successfully), with x,y,z Motors and  and several Inputpins (Input 3 & 4)
i am not able to get any feedback at all.

Hi, I've been thinking on your problem. Please do a full chip erase and re-flash the firmware and DO NOT upload a config file. This will ensure that the default 3 axis step generators are loaded. If this does not allow movement (feedback to LinuxCNC) then there is something else like Ethernet going wrong.

MX_Master wrote:

Just tried to convert ST-Link v2 clone to J-Link (using unofficial methods). No luck. Will try a Black Magic Probe firmware.

Of course, we can use a 50 (and more) bucks official debugger/flash tool to upload the firmware, but it's not reasonable for general user. Controller cost is about 100 bucks.

MX_Master, I agree and this will be the challenge for these boards. Having an affordable reprogramming method will be key. I did order a J-OB-V2 from Aliexpress as it apparently can work with an Cortex-M7. It had not shipped after a long time so I've just cancelled the order and ordered from a different seller.

The other approach I'm going to try over the coming days is the DAPlink. I've been researching this week and hopefully we can create a DAPlink with the same USB vendor and product ID as the DAPlink that is on the RT10502 evaluation boards. This would, hopefully, allow the use of the software tools available for those boards, which included a flash loading utility.

How did you determine which pins on the NVEM v2.1 were SWDIO and SWCLK? 

www.nxp.com/products/processors-and-micr...-m7-core:i.MX-RT1050

How is the rt1059 currently configured for boot? Page 197 of the " i.MX RT1050 Processor Reference Manual" 

Also found in this app note  www.nxp.com/docs/en/application-note/AN12107.pdf
"The boot ROM uses the state of the BOOT_MODE register and eFUSEs to determine the boot device. For development purposes, the eFUSEs used to determine the boot device may be overridden using the GPIO pin inputs."

I'm guessing the OEM has set the eFuses to boot from the QSPI flash. This should not stop a SWD connection (I hope).

I've just got a DAPlink buid environment working and compiled the DAPlink firmware for the ST-Link v2. First step is to check the standard stm32f103xb_bl firmware is working before trying to modify the USB vendor and product ID's. Fingers crossed

SWCLK/SWDIO/GND must be in same order for different versions of the PCB. Because it's logically right But I can't figure it out right now, because a solder station isn't available for me now. I tried to change clk/io pins while using the DAPLink (ST-LINK v2 clone), but with no luck.

Yes, I think for the OEMs eFuses (or values softly set by a bootloader) must be set for the boot via SPI flash. It's also logically right

One more option for the quick firmware download - use a cheap SPI flash programmers like this aliexpress.ru/item/32793476447.html . If a built-in bootloader allows to use any SPI flash firmware (without any checks), this method will be the easiest way for us and other users.

SPI programmer is probably the way to go. Just have to verify that there are no problems with it working in circuit.