RDM on Arduino - E1.20 RDM (Remote Device Management) Protocol Forums

rodb70 · September 27th, 2018

saiteja,

A follow up from previous post.
Yesterday I was working on a demo board with LPC845 Its the LPCXpresso845MAX NXP number OM13097.

I found an issue with IAP (In-Application Programming) no matter what I did I was getting an invalid command return code from the ROM functions. So I when to the NXP forums and had a read around and discovered that an earlier version of this chip LPC824 had a similar issue the reported also detailed a work around. I tried the same work around on my board and it work. It turns out either the User Manual is wrong or the ROM has a bug in it. I've posted this issue on the NXP forums to see what if anything NXP will do with this issue.

Time wise, this took me all day to figure out as I spend a lot of time debugging my code to make sure I was not making a mistake. This meant I was using the debugger and single stepping at assembly instruction level to verify I was calling the ROM function with the correct vales in the required registers.

So the results of this are that I have a functional '"work around"/code that allows me to call into the ROM IAP functions to perform required tasks and can start working on the next steps. Also I have raised an issue with NXP in their forums to help others and NXP improve their product.

Hang in there this stuff is not easy many people give up. When I was debugging RDM comms I used an oscilloscope to verify my turn around timings to the uS were withing standard. I used a 2nd uart to dump the buffers out on the responded to verify that I was receiving the RDM packet correctly. I also dumped out my reply packet before sending it to verify I was sending a correct reply packet. I also used a logic analyser on the TX, RX, and switch lines of the RS-485 driver to verify I was doing the correct thing at the correct time.
My testing was against OLA using my own Enttec USBPro to send and receive DMX / RDM packets.
OLA has its own set of issues as well that would cause it to crash when I sent the wrong data in a reply packet.

Thread Tools	Search this Thread
Show Printable Version Email this Page	Search this Thread: Advanced Search
Display Modes
Switch to Linear Mode Hybrid Mode Switch to Threaded Mode

September 27th, 2018	#1
rodb70 Junior Member Join Date: Jun 2016 Posts: 5	saiteja, A follow up from previous post. Yesterday I was working on a demo board with LPC845 Its the LPCXpresso845MAX NXP number OM13097. I found an issue with IAP (In-Application Programming) no matter what I did I was getting an invalid command return code from the ROM functions. So I when to the NXP forums and had a read around and discovered that an earlier version of this chip LPC824 had a similar issue the reported also detailed a work around. I tried the same work around on my board and it work. It turns out either the User Manual is wrong or the ROM has a bug in it. I've posted this issue on the NXP forums to see what if anything NXP will do with this issue. Time wise, this took me all day to figure out as I spend a lot of time debugging my code to make sure I was not making a mistake. This meant I was using the debugger and single stepping at assembly instruction level to verify I was calling the ROM function with the correct vales in the required registers. So the results of this are that I have a functional '"work around"/code that allows me to call into the ROM IAP functions to perform required tasks and can start working on the next steps. Also I have raised an issue with NXP in their forums to help others and NXP improve their product. Hang in there this stuff is not easy many people give up. When I was debugging RDM comms I used an oscilloscope to verify my turn around timings to the uS were withing standard. I used a 2nd uart to dump the buffers out on the responded to verify that I was receiving the RDM packet correctly. I also dumped out my reply packet before sending it to verify I was sending a correct reply packet. I also used a logic analyser on the TX, RX, and switch lines of the RS-485 driver to verify I was doing the correct thing at the correct time. My testing was against OLA using my own Enttec USBPro to send and receive DMX / RDM packets. OLA has its own set of issues as well that would cause it to crash when I sent the wrong data in a reply packet.