Create FreeRTOS Repository

[Geramy]

Hey Scott,

If you would like to make a repository specific for RTOS I’ll work on setting up the initial project. I think faster communications like you talked about will take this firmware another step up perhaps past the level of the mesa cards because of availability and cost :) plus more communication time means lower latencies between LinuxCNC and motion card and means faster velocity with less errors and that’s exciting enough, that will make probing even more stable too.

[Geramy]

This is really interesting, https://mcuoneclipse.com/2020/04/15/freertos-task-runtime-statistics-for-nxp-i-mx-rt1064/

[Geramy]

I would recommend possibly ThreadX as apparently it is more safe for real time systems, where its actually certified as real-time for medical industry and luckily this rt1052 gets a free pass and can use it without any extra fee's.

LICENSED HARDWARE LIST

Last Updated: 2023-02-10

Microsoft has entered into OEM Agreements with manufacturers of the following microprocessors and microcontrollers (the “hardware”) to enable those manufacturers to include and distribute Azure RTOS in certain hardware. If you have obtained and/or are developing on microprocessor(s) and/or microcontroller(s) (“hardware”) listed below you inherit the “Distribution and Production Use” rights in Section 2 of the Microsoft Software License Terms for Microsoft Azure RTOS. If hardware is not listed below, you do not have those rights.

STMicroelectronics:

STM32 MCUs
STM32 MPUs

MediaTek:

MT3620 MCU (Azure Sphere)

Microchip:

PIC 32-bit MCUs
SAM 32-bit MCUs
SAM 32-bit MPUs

NXP:

i.MX RT10xx and RT116x/7x series crossover MCUs
LPC5500 series
MCX N series

Renesas:

Synergy Platform
RX Family of MCUs
RA Family of MCUs
RZ Family of MPUs

[Geramy]

How much external ram does our device have? Do you have those specifications?

[scottalford75]

I think FreeRTOS will be an ok first step as it's packaged with MCUXpresso. I'll start to have a look during the week, work permitting.

[scottalford75]

Azure RTOS is now in SDK builder! Just downloading now.

[Geramy]

I got it all packaged together with ethernet and threads :), the SDK Builder sucks sometimes to get it all right, you will need threadx and netxduo

[Geramy]

You can take a look here, I have to do modifications to 8720a and some other parts of the ethernet jungle. mainly adapting from two different styles I guess or versions. Mainy with Phy_Init, I have receiving working, in theory, doesnt compile yet haha. https://github.com/Geramy/Remora_rt1052_AzureRTOS_Test

[Geramy]

I created 3 Threads, Networking, Control, and DMA. I assume we would have 3 threads so that we can do monitoring and figure out how much cpu usage each one is using so we can do optimizing :) that will be super fun! Oh yeah I have no idea yet how to implement all that stuff you got into the Azure RTOS, but Azure RTOS real-time is certified for medical whereas FreeRTOS is not and people state that Azure RTOS is more real-time than FreeRTOS which is what we need when we're talking about a CNC.

[Geramy]

Do you still want to use timers or just go straight to threading and skip timers? If you could message me a basic architecture here. I’m looking at messaging queues but to be honest there’s almost no point in that when it’s not really multiple core type threading and it’s a lot of overhead I think instead of just using a mutex. I’m working on making remora DMA classes to handle all the setup for DMA and I’ll do the same for the following stuff inside the main cpp file, try to cut down the file a little but not too much that we are super heavy in a ton of objects.

[Geramy]

I was going to move everything to C++ but to be honest the amount of heap/stack memory available is so low I think it might just be a bad idea...... thoughts, because i keep running out of memory?

[scottalford75]

We can probably move away from timers all together and have the control thread and Sevro thread objects run at +2 times the LinuxCNC servo frequency to ensure up to date tx data for the Ethernet thread. Software PWM module would be an issue without a timer tough.

In MCUXpresso the heap and stack size can be increased. I had to do this when I was working on the C++ version. That said, the DMA config stuff could be left as C code as there is only one instance of that needed. The module objects make sense in C++

I forked your test repo, but could not get it to compile...

[scottalford75]

Just updated my fork and has a look at your latest updated. Nice work, I must say! I'd change the base_thread to be called the servo_thread (slower). The servo thread iterator could then sit in the state machine.

[Geramy]

haha thanks! I tried my best, but man always when you start a new project or start on a new project you really got to dig deep and figure out how it all should come together lol. Like an art almost. I got compiling but I think my flash start and length is wrong. But thats fine I won't be able to actually test my code until friday. So then we got 4 Threads, Base, DMA, Servo, Networking? I did notice the DMA in this instance really has no way to be C++ unless we defined multiple buffers inth e case we were gonna run multiple DMA classes but again only one DMA unit with 16 channels so it doesnt matter in this case. I was trying to find if they had C++ classes for allocating memory in a non cachable area but i cant find anything and then the whole tcdMemory thing, I don't really understand whats going on there except it looks like we are aligning it inside the memory? but not too sure what its for.

[Geramy]

for the software pwm we can let Azure RTOS handle the timing, how about the messaging queues? Do you think we should switch to Azure RTOS Messaging queue system or just use the mutex and stick with raw variables. I'm thinking queue and stuff is going to add overhead and to be honest it would be nice because then we are using the system how we should, but if there is no extra RAM sticks on this controller board we are going to burn a lot of space for something we don't absolutely need because its only technically one core and we don't need queues only mutex so we don't get collisions.

[scottalford75]

I'm on the learning curve here with ThreadX and how the timing is determined, so I'm guessing we could use the underlying thread timing as the time base for modules like PWM. I'd keep things as simple as possible and then if needed move to more elaborate stuff. So DMA going back to the C implementation so save memory do you think?

On Wed, Sep 13, 2023 at 8:53 AM Geramy @.***> wrote:

for the software pwm we can let Azure RTOS handle the timing, how about the messaging queues? Do you think we should switch to Azure RTOS Messaging queue system or just use the mutex and stick with raw variables. I'm thinking queue and stuff is going to add overhead and to be honest it would be nice because then we are using the system how we should, but if there is no extra RAM sticks on this controller board we are going to burn a lot of space for something we don't absolutely need because its only technically one core and we don't need queues only mutex so we don't get collisions.

— Reply to this email directly, view it on GitHub https://github.com/scottalford75/Remora-RT1052-cpp/issues/4#issuecomment-1716625186, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGBMVIPX54R2LVQUU5UCKTTX2DRWNANCNFSM6AAAAAA4RPIAKQ . You are receiving this because you commented.Message ID: @.***>

[Geramy]

I think I will leave it since we have to get the DMA stuff working inside other modules like tftp but i'll drop the memory usage as much as possible and just use static variables from configuration I already dropped the memory to 80% I think. Which is very close to what it was before. But I agree on not trying to move more stuff to C++ just only what is really needed, i'm so used to classes and stuff its rough not to be able to use them haha.

[Geramy]

The networking was actually using all the SRAM_DTC haha, I had packet size at like 1536 and then 80 total packets could be stored in the buffer, I changed it to 512 byte but I think we can lower it to the lowest amount of space needed for ICMP and LinuxCNC is only 68 bytes right, so i'll look that up and see about dropping it some more, but there is plenty of space now to class some more stuff up.

[Geramy]

Which thread or frequency is in charge of communications with LinuxCNC right now? Servo or Base Frequency? I would like for us to communicate anytime there is a change, so maybe what we can do is actually have a messaging queue for sending data to LinuxCNC, I was thinking before maybe not, but actually I think it makes sense for us to use some queues to send data to DMA, Servo or PWM threads, one for each thread maybe. That will reduce need for mutexes. The other thing is the only thread maybe we should have is the networking thread where we can actually sleep so that we dont have thread starvation. We have to technically tell a thread that it gets to skip a tick for the other threads to actually run. I guess what might help is to know whats the best and worse case scenario for LinuxCNC networking. What would be a good latency and a bad latency and that will get us a best and worse case for us to let it sleep a few ticks so it doesn't starve the other threads or timers.

[scottalford75]

Yes, not a lot of incoming data to be stored from LinuxCNC and we process it straight away. I've just read through the ThreadX docs. We'll need to think about thread scheduling and priority. The underlying ticker is 10ms, with the LinuxCNC servo thread being 1000ms. Within that 1000ms we need to process UDP command packet, update servo thread data, respond with a UDP feedback packed, and run the DMA calcs, which at 500 khz for 6 axes can take up to 700ms (but unlikely to run all 6 axes at 500khz simultaneously).

DMA calcs will need to have the highest priority to ensure we get the calcs done within the servo period.

Maybe the servo (control loop) twice in a LinuxCNC servo period.

Ethernet....

On Wed, Sep 13, 2023 at 9:48 AM Geramy @.***> wrote:

The networking was actually using all the SRAM_DTC haha, I had packet size at like 1536 and then 80 total packets could be stored in the buffer, I changed it to 512 byte but I think we can lower it to the lowest amount of space needed for ICMP and LinuxCNC is only 68 bytes right, so i'll look that up and see about dropping it some more, but there is plenty of space now to class some more stuff up.

— Reply to this email directly, view it on GitHub https://github.com/scottalford75/Remora-RT1052-cpp/issues/4#issuecomment-1716713225, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGBMVIKBAFXM4KUWQGVJ7E3X2DYEJANCNFSM6AAAAAA4RPIAKQ . You are receiving this because you commented.Message ID: @.***>

[Geramy]

Wow, really its not a whole lot of math going on here, what slow little processors haha xD I guess we have one floating point Logic Unit we get to use per tick right so 600MHZ if we have 6 FPU calculations that's 100MHZ left over. I still don't get the calculations and stepping 100%, Your saying the frequency command comes in and then when the DMA next updates, we run the calculations and then later make the steps? or we do it all in one, how well are all the motors stepped in sync, this way? I need to understand this part better. When I look at the ethernet stuff I see it like, we receive data and then we send data. I don't see any notifying or anything, but I assume that everything is live more or less, so after it receives data, it uses that as an excuse to send whatever it has inside the buffers?

[Geramy]

I recommend we leave DMA at a set frequency and then do some of the math thats inside the dma stepgen "predetermined" so we can reduce required time needed to run the math, for instance inside DMA we do (BUFFER_COUNTS * PRU_SERVOFREQ), instead we can say this math is pre-determined and we can put some of this math like inside the "kernel class" and have it pull from where or configurations even, then when the user updates via json the actual frequency it doesnt do this math per update, just per startup. Something like that we can do all over the program where we need to optimize and reduce math. Right now the debug version i'm not sure if it compiles so that this part is already calculated or if it runs it at time of execution.

[Geramy]

Maybe I get whats going on here now a bit more, the PIT basically signals the pin to pull from the DMA Buffer every set frequency and that sets the output pin or pins, then in our program we fill that buffer but its on a time scale style fill, where we fill it with 500 steps or 1000 on/offs. Then as time progresses or as the timer pops data off of the buffer its running it directly on the pin, is that correct, more or less?

[scottalford75]

Hopefully the compiler optimises the constant defines like BUFFER_COUNTS * PRU_SERVOFREQ. The only Floating point calcs is to convert the frequency command into the DDS add value, which only happens once per servo period per axis. While one DMA buffer is being sent to the port, we're preparing the next. Which works as the step count is correct at the end of the servo period.

With the current version of Remora that data is updated when the packet is received, the stepgens get this data on the next base thread execution (40khz), so effectively straight away. The position data is also updated at the base thread frequency so the feedback packet is fresh as well. But as you said no strict synchronisation.

Your understanding of the DMA implementation is spot on. But we only put a 1 in the buffer when we need the output to toggle (change state), so a little less math than having to fill the whole buffer. Which is why it's super quick at low step rates.

On Wed, Sep 13, 2023 at 11:27 AM Geramy @.***> wrote:

Maybe I get whats going on here now a bit more, the PIT basically signals the pin to pull from the DMA Buffer every set frequency and that sets the output pin or pins, then in our program we fill that buffer but its on a time scale style fill, where we fill it with 500 steps or 1000 on/offs. Then as time progresses or as the timer pops data off of the buffer its running it directly on the pin, is that correct, more or less?

— Reply to this email directly, view it on GitHub https://github.com/scottalford75/Remora-RT1052-cpp/issues/4#issuecomment-1716798061, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGBMVINRSQ2SBNBOAXDE4KTX2EDZBANCNFSM6AAAAAA4RPIAKQ . You are receiving this because you commented.Message ID: @.***>

[Geramy]

how many timer ticks per second do we want? I can just change it to 1000, wouldn't that be the same as before making the code more compatible?

[Geramy]

Timer.cpp is now using the ThreadX timer, I also changed the following, /for (int i = 0; i < BUFFER_SIZE; i++) { rxData.rxBuffer[i] = rxBuffer.rxBuffer[i]; }/ memcpy(&rxBuffer.rxBuffer, rxBuffer.rxBuffer, sizeof(uint8_t) * BUFFER_SIZE); does that still work with the networking packing system? Never used C to do network packet packing before lol

[Geramy]

Is the PIT Timer also updating the step count as it’s going through each step?

[Geramy]

Let me know if you can take a look at my latest commit, I think I nearly have everything linked together, I just havn't put RemoraKernel inside of main basically, or well main of threadx. But its all there and merged over except DMA isn’t inside the kernel init. I was wondering if you could review it and give me some feedback and what I should do with DMA, should it be the same a pruThread which is really a ThreadX Timer? Also I have mutexes inside the networking being used, I just havn't put them inside the other threads yet. But most of the major hard work is done, just some tidying up and some small modifications, not really sure what to do with this crazy extern volatile stuff yet, i'm thinking shoving them inside the kernel or main but not sure yet.

[Geramy]

Good morning, so when is the correct moment we need to run this?

if (g_transferDone)
        {

            // clear the DMA buffer ready for next use
            if (stepgenDMAbuffer)
            {
                memset(stepgenDMAbuffer_0, 0, sizeof(stepgenDMAbuffer_0));
            }
            else
            {
                memset(stepgenDMAbuffer_1, 0, sizeof(stepgenDMAbuffer_1));
            }

            // switch buffers
            stepgenDMAbuffer = !stepgenDMAbuffer;

            // prepare the next DMA buffer
            for (iterDMA = vDMAthread.begin(); iterDMA != vDMAthread.end(); ++iterDMA) (*iterDMA)->runModule();

            g_transferDone = false;
        }

Should this be ran after each network packet received, or do we need to calculate how long each buffer fill will last for based on frequency and then set the timer based on that, I would think when the buffer runs out we would run it right? it seems that g_transferDone is true once it finishes the transfer or exhausts the buffer right?

[Geramy]

I did as we talked about and put DMA inside it’s own thread, the mutex should force it to sleep at least when it’s being used by the networking. But I still need to figure out how we can calculate the optimal sleep time for the DMA class.

[Geramy]

there is only two ways to do it, change ticks per second to way more like microseconds and not milliseconds or we can pause the thread and start the thread based on networking and transfer being done? What do you think?

[scottalford75]

Ideally we should try to synchronise the DMA with the LinuxCNC servo thread. We could do this by using the first received packet to trigger the first stepgen calcs and then kick-off the DMA transfers. The DMA complete callback then taking care of setting g_transferDone and messaging (?) the DMA thread. This is my first exposure to an RTOS so loving watching how you are piecing this together.

[Geramy]

Actually I really like that idea I been battling with myself how i'm gonna do this haha. I have a callback that gets called when we receive data from the networking function. It gets sent to the kernel so we get notification, but its on the networking thread of course inside the kernel class. I think adding the messaging queue will be freaking fantastic instead of having to change the ticks per second to microseconds which who knows what problems that could bring, the dma thread will wait forever until there is a message giving time to every other thread or timer to do its task. :)

[Geramy]

You can do another pull, dma is finished, I have implemented semaphores to stop dma from running a bunch of times when the original dma buffers are not finished being ran. This will leave more time for the networking, the only other thing is we pause the dma when we receive a new packet as to not cause any collisions. I need someone to test it out haha, I don't have my device with me, i'm out of town. We are still missing the TFTP server which I know we need but i'm not too interested in that right now haha.

[Geramy]

Continued working through the project, moved all create functions inside their respective classes as static functions of those classes and got everything compiling good, only using 26.7KB of DTC and I think the program should technically work just like before minus TFTP because I just havn't had the time to get that moved over yet and I cant test the ethernet, if you have a chance to test it let me know what happens, hopefully the board doesnt blow up haha.

[Geramy]

I put binaries inside my release tab on my repository.

[scottalford75]

I've just sync'd to your latest work. I sill cannot get it to compile with the following error.

"Internal Builder: Cannot run program "arm-none-eabi-c++": Launching failed"

[scottalford75]

Hi, so I just loaded the binary and no go. Nothing outputted on the serial, no network lights etc.

[Geramy]

I’m using Internal builder

[Geramy]

I got my board in my hand working on a remora network kernel for testing in C#, to simulate linuxcnc

[Geramy]

Found something, some sort of heap overflow, submitting new commit to fix the program errors so you can debug it directly.

[Geramy]

I've got the stack at 256kb and the heap constantly changing, disabled all function calls and everything, just basic OS and still a big fat no go.

[Geramy]

sticking this here for reference and as a bin, when debugging at debug level 4 i get these messages. MCUXpresso IDE RedlinkMulti Driver v11.7 (Mar 22 2023 09:52:55 - crt_emu_cm_redlink build 13) Found chip XML file in C:/Users/Geramy/Documents/MCUXpressoIDE_11.7.1_9221/workspace/remora_rt1052_AzureRTOS/Debug\MIMXRT1052xxxxB.xml ( 5) Remote configuration complete Reconnected to existing LinkServer process. ============= SCRIPT: RT1050_connect.scp ============= RT1050 Connect Script DpID = 0BD11477 APID = 0x04770041 Disabling MPU Configure FlexRAM for 256KB OC RAM, 128KB I-TCM, 128KB D-TCM Finished ============= END SCRIPT ============================= Probe Firmware: CMSIS-DAP_LU (jixin.pro) Serial Number: LU_2022_8888 VID:PID: C251:F001 USB Path: \?\hid#vid_c251&pid_f001&mi_02#7&723e913&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030} Using memory from core 0 after searching for a good core debug interface type = CoreSight DP (DAP DP ID 0BD11477) over SWD TAP 0 processor type = Cortex-M7 (CPU ID 00000C27) on DAP AP 0 number of h/w breakpoints = 8 number of flash patches = 0 number of h/w watchpoints = 4 Probe(0): Connected&Reset. DpID: 0BD11477. CpuID: 00000C27. Info: Debug protocol: SWD. RTCK: Disabled. Vector catch: Disabled. Content of CoreSight Debug ROM(s): RBASE E00FD000: CID B105100D PID 000008E88C ROM (type 0x1) ROM 1 E00FE000: CID B105100D PID 04000BB4C8 ROM (type 0x1) ROM 2 E00FF000: CID B105100D PID 04000BB4C7 ROM (type 0x1) ROM 3 E000E000: CID B105E00D PID 04000BB00C Gen SCS (type 0x0) ROM 3 E0001000: CID B105E00D PID 04000BB002 Gen DWT (type 0x0) ROM 3 E0002000: CID B105E00D PID 04000BB00E Gen (type 0x0) ROM 3 E0000000: CID B105E00D PID 04000BB001 Gen ITM (type 0x0) ROM 2 E0041000: CID B105900D PID 04001BB975 CSt ARM ETMv4.0 type 0x13 Trace Source - Core ROM 2 E0042000: CID B105900D PID 04004BB906 CSt type 0x14 Debug Control - Trigger, e.g. ECT ROM 1 E0040000: CID B105900D PID 04000BB9A9 CSt type 0x11 Trace Sink - TPIU ROM 1 E0043000: CID B105F00D PID 04001BB101 Sys (type 0x0) NXP: MIMXRT1052xxxxB DAP stride is 1024 bytes (256 words) Inspected v.2 External Flash Device on SPI using SFDP JEDEC ID MIMXRT1050_SFDP_QSPI.cfx Image 'iMXRT1050_SFDP_QSPI Mar 21 2023 13:24:31' Opening flash driver MIMXRT1050_SFDP_QSPI.cfx Sending VECTRESET to run flash driver Flash variant 'JEDEC_SFDP_Device' detected (4MB = 64*64K at 0x60000000) Closing flash driver MIMXRT1050_SFDP_QSPI.cfx Connected: was_reset=false. was_stopped=true Awaiting telnet connection to port 3330 ... Command In: $qSupported:multiprocess+;swbreak+;hwbreak+;qRelocInsn+;fork-events+;vfork-events+;exec-events+;vContSupported+;QThreadEvents+;no-resumed+ GDB feature used multiprocess+ Reply: +$PacketSize=4000;qXfer:memory-m... Command In: $vMustReplyEmpty Unsupported command v - in 'MustReplyEmpty#3a' Command In: $! Reply: +$OK Command In: $Hg0 Reply: +$OK Command In: $qXfer:features:read:target.xml:0,1000 Reply: +$l<?xml version="1.0"?><!DOCTYP... Command In: $QNonStop:0 GDB nonstop mode disabled (using allstop mode) Reply: +$OK Command In: $qTStatus Reply: +$ Command In: $? Reply: +$S05 Command In: $qfThreadInfo Reply: +$m1OK Command In: $qsThreadInfo Reply: +$lOK Command In: $qAttached Unsupported command q - in 'Attached#8f' Command In: $Hc-1 Reply: +$OK Command In: $qC Reply: +$QC1 Command In: $qOffsets Reply: +$ Command In: $g Note PC=0x00201414 Reply: +$000000000000000000000000000000... Command In: $qXfer:memory-map:read::0,1000 Reply: +$l<?xml version="1.0"?><!DOCTYP... Command In: $m60026290,2 Reply: +$08b5 Command In: $qfThreadInfo Reply: +$m1OK Command In: $qsThreadInfo Reply: +$lOK Command In: $qSymbol:: Reply: +$qSymbol:707852656164795461736b... Command In: $qSymbol::707852656164795461736b734c69737473 Reply: +$qSymbol:7850656e64696e67526561... Command In: $qSymbol::7850656e64696e6752656164794c697374 Reply: +$qSymbol:7853757370656e64656454... Command In: $qSymbol::7853757370656e6465645461736b4c697374 Reply: +$qSymbol:7844656c61796564546173... Command In: $qSymbol::7844656c617965645461736b4c69737431 Reply: +$qSymbol:7844656c61796564546173... Command In: $qSymbol::7844656c617965645461736b4c69737432 Reply: +$qSymbol:707844656c617965645461... Command In: $qSymbol::707844656c617965645461736b4c697374 Reply: +$qSymbol:70784f766572666c6f7744... Command In: $qSymbol::70784f766572666c6f7744656c617965645461736b4c697374 Reply: +$qSymbol:785461736b735761697469... Command In: $qSymbol::785461736b7357616974696e675465726d696e6174696f6e Reply: +$qSymbol:785363686564756c657252... Command In: $qSymbol::785363686564756c657252756e6e696e67 Reply: +$qSymbol:757843757272656e744e75... Command In: $qSymbol::757843757272656e744e756d6265724f665461736b73 Reply: +$qSymbol:707843757272656e745443... Command In: $qSymbol::707843757272656e74544342 Reply: +$qSymbol:4672656552544f53446562... Command In: $qSymbol::4672656552544f534465627567436f6e666967 Reply: +$qSymbol:706f7274417263685f4e61... Command In: $qSymbol::706f7274417263685f4e616d65 Reply: +$qSymbol:5f74785f7468726561645f... Command In: $qSymbol:2020087c:5f74785f7468726561645f63757272656e745f707472 Reply: +$qSymbol:5f74785f7468726561645f... Command In: $qSymbol:20200880:5f74785f7468726561645f657865637574655f707472 Reply: +$qSymbol:5f74785f7468726561645f... Command In: $qSymbol:20200878:5f74785f7468726561645f637265617465645f707472 Reply: +$qSymbol:5f74785f7468726561645f... Command In: $qSymbol:20200874:5f74785f7468726561645f637265617465645f636f756e74 Reply: +$qSymbol:5f74785f7468726561645f... Command In: $qSymbol:202000bc:5f74785f7468726561645f73797374656d5f7374617465 Reply: +$qSymbol:5f74785f7468726561645f... Command In: $qSymbol:20200894:5f74785f7468726561645f7072696f726974795f6c697374 Reply: +$qSymbol:5f74785f6275696c645f6f... Command In: $qSymbol:20200870:5f74785f6275696c645f6f7074696f6e73 Reply: +$qSymbol:5f6b65726e656c Command In: $qSymbol::5f6b65726e656c Reply: +$qSymbol:5f6b65726e656c5f746872... Command In: $qSymbol::5f6b65726e656c5f7468726561645f696e666f5f6f666673657473 Reply: +$qSymbol:5f6b65726e656c5f746872... Command In: $qSymbol::5f6b65726e656c5f7468726561645f696e666f5f6e756d5f6f666673657473 Reply: +$qSymbol:5f6b65726e656c5f746872... Command In: $qSymbol::5f6b65726e656c5f7468726561645f696e666f5f73697a655f745f73697a65 Reply: +$qSymbol:7a5f7379735f706f73745f... Command In: $qSymbol::7a5f7379735f706f73745f6b65726e656c Reply: +$qSymbol:5f6d71785f76657273696f... Command In: $qSymbol::5f6d71785f76657273696f6e5f6e756d626572 Reply: +$qSymbol:5f6d71785f76656e646f72 Command In: $qSymbol::5f6d71785f76656e646f72 Reply: +$qSymbol:5f6d71785f6b65726e656c... Command In: $qSymbol::5f6d71785f6b65726e656c5f64617461 Reply: +$qSymbol:4d51585f696e69745f7374... Command In: $qSymbol::4d51585f696e69745f737472756374 Reply: +$qSymbol:5f6d71785f64656275675f... Command In: $qSymbol::5f6d71785f64656275675f636f6e666967 Azure RTOS ThreadX symbol(s) found:

• "_tx_thread_current_ptr" 0x2020087C
• "_tx_thread_execute_ptr" 0x20200880
• "_tx_thread_created_ptr" 0x20200878
• "_tx_thread_created_count" 0x20200874
• "_tx_thread_system_state" 0x202000BC
• "_tx_thread_priority_list" 0x20200894
• "_tx_build_options" 0x20200870 Azure RTOS ThreadX stack backtrace is enabled Reply: +$OK Command In: $qRcmd,6f6e646973636f6e6e65637420636f6e74 Reply: +$OK Command In: $vCont? Reply: +$vCont;c;C;S;s;r Command In: $qRcmd,73656d69686f737420656e61626c65 Reply: +$OK Command In: $vFlashErase:60000000,00030000 Reply: +$OK Command In: $vFlashWrite (len=8214, rest clipped) Reply: +$OK Command In: $vFlashWrite (len=16376, rest clipped) Reply: +$OK Command In: $vFlashWrite (len=16369, rest clipped) Reply: +$OK Command In: $vFlashWrite (len=16373, rest clipped) Reply: +$OK Command In: $vFlashWrite (len=16368, rest clipped) Reply: +$OK Command In: $vFlashWrite (len=16367, rest clipped) Reply: +$OK Command In: $vFlashWrite (len=16379, rest clipped) Reply: +$OK Command In: $vFlashWrite (len=16369, rest clipped) Reply: +$OK Command In: $vFlashWrite (len=16369, rest clipped) Reply: +$OK Command In: $vFlashWrite (len=16372, rest clipped) Reply: +$OK Command In: $vFlashWrite (len=16368, rest clipped) Reply: +$OK Command In: $vFlashWrite (len=13479, rest clipped) Reply: +$OK Command In: $vFlashWrite (len=30, rest clipped) Reply: +$OK Command In: $vFlashWrite (len=55, rest clipped) Reply: +$OK Command In: $vFlashWrite (len=835, rest clipped) Reply: +$OK Command In: $vFlashDone Opening flash driver MIMXRT1050_SFDP_QSPI.cfx (already resident) Sending VECTRESET to run flash driver Flash variant 'JEDEC_SFDP_Device' detected (4MB = 64*64K at 0x60000000) Writing 183348 bytes to address 0x60000000 in Flash 60004000 done 8% (16384 out of 183348) 60008000 done 17% (32768 out of 183348) 6000C000 done 26% (49152 out of 183348) 60010000 done 35% (65536 out of 183348) 60014000 done 44% (81920 out of 183348) 60018000 done 53% (98304 out of 183348) 6001C000 done 62% (114688 out of 183348) 60020000 done 71% (131072 out of 183348) (100) at 60020000: 65536 bytes - 196608/183348 Sectors written: 2, unchanged: 1, total: 3 Erased/Wrote sector 0-2 with 183348 bytes in 7885msec Closing flash driver MIMXRT1050_SFDP_QSPI.cfx Flash Write Done Flash Program Summary: 183348 bytes in 7.89 seconds (22.71 KB/sec) Starting execution using system reset and halt target Reply: +$OK Command In: $Pf=dc220060 GDB trying to set entry point of 0x600022DC, but correct entry is 0x201414 Reply: +$OK Command In: $p19 Reply: +$00000001 Command In: $m60026290,2 Reply: +$4040 Command In: $qfThreadInfo Reply: +$m1OK Command In: $qsThreadInfo Reply: +$lOK Command In: $qRcmd,53574f2064617461736f75726365 Reply: +$OK Command In: $qfThreadInfo Reply: +$m1OK Command In: $qsThreadInfo Reply: +$lOK Command In: $m600022dc,4 Reply: +$00000000 Command In: $qThreadExtraInfo,1 Reply: +$52756e6e61626c65 Command In: $m600069c0,40 Reply: +$404040400000000040404040000000... Command In: $m6001ac00,40 Reply: +$404040400000000040404040000000... Command In: $m600069e6,2 Reply: +$0000 Command In: $m6001ac10,2 Reply: +$4040 Command In: $m600069e6,2 Reply: +$0000 Command In: $m6001ac10,2 Reply: +$4040 Command In: $m6001abc0,40 Reply: +$404040400000000040404040000000... Command In: $m6001abf2,2 Reply: +$4040 Command In: $m6001abf2,2 Reply: +$4040 Command In: $qfThreadInfo Reply: +$m1OK Command In: $qsThreadInfo Reply: +$lOK Command In: $qThreadExtraInfo,1 Reply: +$52756e6e61626c65 Command In: $Z1,600069e6,2 Reply: +$OK Command In: $Z1,6001abf2,2 Reply: +$OK Command In: $Z1,6001ac10,2 Reply: +$OK Command In: $vCont;c state - running or following reset request - re-read of state failed - rc Nn(05). Wire ACK Wait in DAP access

[Geramy]

Fixed it, i forgot to include two files that tells it where to boot from. Woo! Submitted new commit, should be working. your problem your having with compiling is because i'm using the internal builder but you can change it inside the properties of build.

[scottalford75]

Thanks, I did a complete refresh of my fork and it now compiles and I can debug. No serial output, no ethernet activity. What are you experiencing?

[Geramy]

I get a error status 7 on nx_ip_create, not sure why. if I want to initialize the clocks manually for the ethernet card I can but that doesnt help anything. Not sure if we have a reference wrong or what. Error 7 means invalid ptr "#define NX_PTR_ERROR 0x07" Also just submitted my last changes too, until i can fix the network error. Everything looks good to me.

[Geramy]

Here's what MS has to say.

Parameters ip_ptr: Pointer to control block to create a new IP instance. name: Name of this new IP instance. ip_address: IP address for this new IP instance. network_mask: Mask to delineate the network portion of the IP address for sub-netting and super-netting uses. default_pool: Pointer to control block of previously created NetX packet pool. ip_network_driver: User-supplied network driver used to send and receive IP packets. memory_ptr: Pointer to memory area for the IP helper thread’s stack area. memory_size: Number of bytes in the memory area for the IP helper thread’s stack. priority: Priority of IP helper thread.

Return Values NX_SUCCESS (0x00) Successful IP instance creation. NX_NOT_IMPLEMENTED (0x4A) NetX library is configured incorrectly. NX_PTR_ERROR (0x07) Invalid IP, network driver function pointer, packet pool, or memory pointer. NX_SIZE_ERROR (0x09) The supplied stack size is too small. NX_CALLER_ERROR (0x11) Invalid caller of this service. NX_IP_ADDRESS_ERROR (0x21) The supplied IP address is invalid. NX_OPTION_ERROR (0x21) The supplied IP thread priority is invalid.`

[Geramy]

I'm also not getting any execution inside the drivers main function.

[Geramy]

I'm going to include netxduo source into the project so we can really see whats going on and fix it.

[Geramy]

Ethernet lights are on and thats working now! But weird the LED lights on the board are all wonky.

[Geramy]

now we have a enet error, but ethernet has its lights on and they flash a bit. Multiple errors reported.

1) Failed to execute MI command: -var-create - * &(s_enetBases) Error message from debugger back end: Attempt to take address of register or constant.

2) Failed to execute MI command: -var-create - * &(s_enetBases) Error message from debugger back end: Attempt to take address of register or constant.

3) Unable to create variable object