Remora - ethernet NVEM cnc board

I connected stlink to my nvmpg to get a dump of the running firmware, it would be interesting to get a copy from someone that has a working to see if there's major difference? Scott, would you be able to take my .bin from my nvmpg and see if it differed from yours? I dont have the skills to reverse engineer things like you did up front but happy to poke about and learn more!

disneysw wrote:

I have read the full thread, wiki and looked at git hub and there are a number of things I am still confused about due to conflicting information.

I am using a standard LinuxCNC distro on an i5 PC. I have erased and programmed an NVEM V5 board (RT1052) using pyocd and the remora-rt1052-NVEM-0.2.1.bin and the board responds to pings at 10.10.10.10.

I cannot upload a config to the remora board due to time outs, but I understand this is to be expected as the firmware has a full config built-in - is this correct or is this the root cause of my issues?

The board outputs the following via the debug port on boot:

        Initializing PHY...

         ## Entering SETUP state


         ## Entering START state

          Starting the threads

         ## Entering IDLE state

I have installed the remora components (remora-eth, remora-nv, remora-nvmpg) into LinuxCNC and I copied various remora configs to my config directory.

Satrting LinuxCNC and using the remova-nv config I can get the x & y steppers to sort of move but I cannot see any inputs change state (I have tried all of them). In the HAL viewer I can see the Remora status as OK and both the servo-thread.time /remora.update-frq.time are updating.

Ultimately I want to set this up for a lathe with x,y and spindle control but for now it is sitting on my desk with two steppers and some switches wired up to the inputs.


So my questions are:

1: have I flashed the correct firmware?
2: do I need to upload a config file to the NVEM - if so why would I get a timeout (this is mentioned by someone else in an earlier post)?
3: If the above is OK why can I not see any input changes?
4: Do anyone have a Lathe config as a starting point?

Thanks in advance

The default config within the firmware has only three step generators configured. You will need to upload a config, but strange you are getting timeouts..

cncwhacko wrote:

I connected stlink to my nvmpg to get a dump of the running firmware, it would be interesting to get a copy from someone that has a working to see if there's major difference? Scott, would you be able to take my .bin from my nvmpg and see if it differed from yours? I dont have the skills to reverse engineer things like you did up front but happy to poke about and learn more!

Great, yes please send me your bin file from the NVPMG and I can compare to the one from mine that was use to reverse engineer the payload. It will be interesting to see if they have made some changes.

Thanks for the pointer at least I now know what to look at. I tried manually uploading the config file but tftp timeouts (ascii & binary modes) as well:

tftp> status
Connected to 10.10.10.10.
Mode: netascii Verbose: on Tracing: on
Rexmt-interval: 5 seconds, Max-timeout: 25 seconds
tftp> put /tmp/config.txt
putting config.txt to 10.10.10.10:/tmp/config.txt [netascii]
sent WRQ <file=/tmp/config.txt, mode=netascii>
sent WRQ <file=/tmp/config.txt, mode=netascii>
sent WRQ <file=/tmp/config.txt, mode=netascii>
sent WRQ <file=/tmp/config.txt, mode=netascii>
sent WRQ <file=/tmp/config.txt, mode=netascii>
Transfer timed out.

I will download the remora source plus the build system to add some debug messages and  hopefully identify what is happening.

  Attaching the nvmpg .bin I was able to extract from my unit. Hope this helps debug what's going on with the TFT/display oddities!

cncwhacko wrote:

 

File Attachment:

File Name: nvmpg.bin.zip
File Size:22 KB

Attaching the nvmpg .bin I was able to extract from my unit. Hope this helps debug what's going on with the TFT/display oddities!

Hi, thanks but something is not right with the file. It's only 99KB where the hex file I dumped from the MPG with ST-Link Utility is 400KB. On inspection, the file does not look like a valid bin file either.

Let me try once more; quite new to this--This time around: I used st-link utility, from there i plugged address
 
The first time around I had the size set to something smaller as it appeared to be null data after some point? this time i changed the size to 0x07FFFF

New version shows 511KB when unzipped (had to zip to upload here)
 

Hi, the file is a better size but still does not look correct. Please save as a hex file starting from 0x08000000. Below is a snip of a valid NVMPG hex file.
 
 

So four development environments later I can now build Remora from source and create my own bin file (just in case anyone else want to give it a go you need the mxuxpresso IDE).

While looking at the source I discovered it is a single bin file for all hardware boards and the config is what defines which hardware variant is used - I was expecting #ifdefs in the code for the hardware. (So now I am confused about why their are different bin files and why remora-rt1052-3.1.2.bin does not work on my NVEM board).

Anyway my new bin created from the main branch at github.com/scottalford75/Remora-RT1052-cpp generates more debug info and allows a config file to upload via TFTP. But there is still an issue. Basically the unit hangs when nvem-full-config.txt or nvem-basic-config.txt is uploaded (it even stops responding to pings). The unit then needs to be erased and flashed to recover (the config survives a power cycle).

This is the output from the debug port. Obviously the ASSERT is being called leading to the unit hanging but why did the X joint load and not the Y joint:

1. Loading JSON configuration file from Flash memory



2. Parsing JSON configuration file
Config deserialisation - Deserialization succeeded

3. Board Type: NVEM

4. Configuring threads
Creating timer ISR thread 40000
Creating timer ISR thread 1000
Creating DMA thread 500000

5. Loading modules

Creating a std module
Creating an Ethernet communication monitoring module
Creating Pin @
  port = GPIO3
  pin = 0

Base thread object

X - Joint 0 step generator

Creating a std module
Creating Pin @
  port = GPIO21
  pin = 15
Creating Pin @
  port = GPIO21
  pin = 14

Base thread object

Y - Joint 1 step generator

Creating a std module
Creating Pin @
  port = GPIO21
  pin = 13
Creating Pin @
  port = GPIO21
  pin = 12
ASSERT ERROR " instance < ARRAY_SIZE(s_gpioBases) ": file "fsl_gpio.c" Line "60" function name "GPIO_GetInstance"

 

Thanks Scott,

I noticed your image your length is different than mine. After 0x000188B0 in my readout all the data displays as FFFFFFFF. so I set the data size as 0x188C0, which creates a ~236KB hex file. Attaching here and photos of what I  see.

refresh with new size: