Recent Posts

Pages: [1] 2 3 ... 10
1
NXPTM M522XX, KINETIS and i.MX RT / Re: Converting a Teensy4.1 to a MicromodTeensy, Ethernet RMII breaks ethernet sim
« Last post by Ray on September 16, 2026, 05:38:20 PM »
You were EXACTLY correct.  Somehow, I completely missed this one #define:
#define ETH_INTERFACE_CHANNEL     iMX_ENET_2                 // use the second ethernet controller as first interface (1Gb/s if iMX RT 11xx)

Simulator up and running flawlessly.  All pins appear to be configured correctly.

Thanks!

2
NXPTM M522XX, KINETIS and i.MX RT / Re: Converting a Teensy4.1 to a MicromodTeensy, Ethernet RMII breaks ethernet sim
« Last post by mark on September 16, 2026, 03:44:14 PM »
Hi Ray

I just checked in basic support of the MicroModTeensy - see image.

Since this module doesn't have Ethernet the external circuit will define how it is connected and details about the PHY so this is presently inherited from the Teensy 4.1 but it looks like yours uses the second Ethernet and not the first (with a few clocking adjustments).

My note are:
1. #define ETHERNET_COUNT    2
is defined in iMX.h and so will automatically be set when the i.MX RT 106x is in use.
2. I didn't check details about the signal connections but the setup can be checked accurately based on the pin functions displayed when the simulation is running and so is probably Ok based on your checks.
3. The simulator doesn't actually use the pin connections for its Ethernet connection and so such details will probably not be able to result in a simulation issue.
4. You may be missing
#define ETH_INTERFACE_CHANNEL     iMX_ENET_2                 // use the second ethernet controller as first interface (1Gb/s if iMX RT 11xx)
if you connect to the second Ethernet interface. This will allow all Ethernet traffic to be on that one and the simulator will also connect to it.
5. If using dual Ethernet the interface count can be set to 2
#define ETH_INTERFACE_COUNT       2                          // enable two ethernet interfaces
When working with the dual Ethernet connection the simulator will need to know which one to connect to or else can use
Code: [Select]
SIMULATE_DUAL_ENET_CONNECTIONwhich will pass all received frames to both Ethernet interfaces, but I don't think that this is relevant in your case.


In case of general issues with receiving date (when the NIC is correctly selected) I recommend setting a break point in fnCheckThisEthernet() in iMxSim.c, which should be hit whenever any Ethernet data is received (either from the connected NIC or else from a script file). You can then check that it is being handled on the correct Ethernet and see whether it is rejected due to a configuration setting, etc.

Regards

Mark


3
NXPTM M522XX, KINETIS and i.MX RT / Converting a Teensy4.1 to a MicromodTeensy, Ethernet RMII breaks ethernet sim
« Last post by Ray on September 15, 2026, 09:33:57 PM »
I found an old link where Paul S confirmed that RMII can be implemented on the MicroModTeensy. 
Most of this was already setup in the uTasker kinetis_ENET.h   

I needed to add a #define ENET2_REF_CLK2_ON_EMC
I added a new #define  ENET2_ON_MICROMOD   (copy/pasted from the default)[/img]
        #elif defined ENET2_ON_MICROMOD
        _CONFIG_PERIPHERAL(GPIO_B0_12, ENET2_TDATA00, (PORT_DSE_MID | PORT_SRE_FAST)); // ENET2_TDATA00 on GPIO2-12 (alt. function 8)
        _CONFIG_PERIPHERAL(GPIO_EMC_31, ENET2_TDATA01, (PORT_DSE_MID | PORT_SRE_FAST)); // ENET2_TDATA01 on GPIO4-31 (alt. function 8)
        _CONFIG_PERIPHERAL(GPIO_EMC_32, ENET2_TX_EN, (PORT_DSE_MID | PORT_SRE_FAST));    //
        IOMUXC_ENET2_IPP_IND_MAC0_RXDATA_SELECT_INPUT_0 = IOMUXC_ENET2_IPP_IND_MAC0_RXDATA_SELECT_INPUT_0_GPIO_SD_B0_03_ALT8;
        _CONFIG_PERIPHERAL(GPIO_SD_B0_03, ENET2_RDATA00, 0);                // ENET2_RX_DATA00 on GPIO2-20 (alt. function 8)
        IOMUXC_ENET2_IPP_IND_MAC0_RXDATA_SELECT_INPUT_1 = IOMUXC_ENET2_IPP_IND_MAC0_RXDATA_SELECT_INPUT_1_GPIO_SD_B0_04_ALT8;
        _CONFIG_PERIPHERAL(GPIO_SD_B0_04, ENET2_RDATA01, 0);                // ENET2_RX_DATA01 on GPIO2-21 (alt. function 8)
        IOMUXC_ENET2_IPP_IND_MAC0_RXERR_SELECT_INPUT = IOMUXC_ENET2_IPP_IND_MAC0_RXERR_SELECT_INPUT_GPIO_B1_00_ALT8; // special case to select the pad involved in daisy chain
        _CONFIG_PERIPHERAL(GPIO_B1_00, ENET2_RX_ER, 0);                  // ENET2_RX_ER on GPIO2-16 (alt. function 8)


The simulator shows the correct peripheral configuration when I define IP_ETHERNET_INTERFACE_COUNT 2
Also created:
        #define ETHERNET_COUNT    2   // because of 2 ETH_CONTROLLERS
        #define ENET2_REF_CLK2_ON_SD
        #define ENET2_ON_MICROMOD

Unfortunately, something is miss-configured because the simulator is showing a red connect light, and ping, nor http is working now that I have made modifications from the original TEENSY4.1   I'm guessing this is probably nothing more than a #define mistake somewhere, I haven't added any code yet.

I attached a bmp of the simulator showing the peripheral configuration while running
4
NXPTM M522XX, KINETIS and i.MX RT / Re: DIO internal PullDown
« Last post by neil on May 28, 2026, 09:46:06 PM »
Hi Mark,
  I will give that a try. I am using to to read a pin from a modem, the modem keeps this high, then drops to 0 when switched off. But I cant monitor it as always sitting high. I have many units out there now , and would have put a pull down resistor on it but cant get to them. I will just have to use a timeout of these.

Many thanks for your help :)

Best Regards
Neil
5
NXPTM M522XX, KINETIS and i.MX RT / Re: DIO internal PullDown
« Last post by mark on May 28, 2026, 09:33:50 PM »
Hi Neil

I wonder what happens f you connect a 1MOhm resistor to GND from the pin?
If it then goes to '0' it would presumably mean that there is a very low leakage path to 3V but not enough to supply any real current.

Regards

Mark

6
NXPTM M522XX, KINETIS and i.MX RT / Re: DIO internal PullDown
« Last post by neil on May 28, 2026, 06:26:28 PM »
Hi Mark,
  Many thanks for that information. 

Strange though, as when nothing is connected to PA5 (same with a couple of other pins) , it is sitting at 3.3v. 

Best Regards
Neil
7
NXPTM M522XX, KINETIS and i.MX RT / Re: DIO internal PullDown
« Last post by mark on May 28, 2026, 06:04:05 PM »
Hi Neil

Unfortunately AN doesn't have any internal pull-up or pull-down capabilities - see attached image.

Regards

Mark


8
NXPTM M522XX, KINETIS and i.MX RT / DIO internal PullDown
« Last post by neil on May 28, 2026, 02:20:06 PM »
Hi Mark,
  Hope you are doing well..

Its been quite a while since i have done anything on the MFC52259, and dont have anymore much info on programming it. I am wondering if utasker has something I can use   for setting PortA for input and assigning internal pulldown.  Im using the Port A , pin 5 as input as follows:

DDRAN &= ~PORT_AN_BIT5;   //se

if(PORTIN_SETAN & GSM_PWCTRL_PIN)
 ...

But it must be using internal pullups , I really want internal pulldown. Can t add resistor as the units are already in the field.

Many thanks
Neil
9
µTasker general / Re: uTasker Utilities
« Last post by mark on April 25, 2026, 11:42:28 AM »
The utilities run in a Windows environment and require some Microsoft DLLs that are generally present.
In some situations (a new PC which has not had general programs installed yet) the DLLs may be missing.
A typical error message is
"The code excecution cannot proceed because VCRUNTIME140.dll was not found. Reinstalling the program may fix this problem"

If unsure whether this issue is present or not please use the command "uTaskerConvert.exe -v" in a DOS shell to clearly see the result.

In case of this issue existing, the DLL can be installed from
https://learn.microsoft.com/en-us/cpp/windows/latest-supported-vc-redist?view=msvc-170

Note that many programs that are installed will supply the DLL, since they also need it in order to be able to operate, and so it is rare that this is required.
10
NXPTM M522XX, KINETIS and i.MX RT / Re: I sometimes have hard-faults but when they are ignored all work - what is going
« Last post by mark on March 08, 2026, 10:28:59 PM »
Hi

Example: When peripherals are enabled (gated) and then used it is possible that between gating and it being ready there is a delay (in the synchronisation of clock domains) that means that the code using the peripheral will use it slightly too early.
What happens is that there is a hard fault. If the hard fault lands in a forever loop it fails. If the hard fault simply returns it then repeats (and works) and all is fine and it continues.
That is, there can be 'temporary' hard faults that are not really critical.
Often they can be avoided by using instruction / data barrier commands like

asm volatile ("dsb 0xf":::"memory");
asm volatile ("isb 0xf":::"memory");

which cause the processor to wait until the previous peripheral write operations have completed but this can be fiddly.

What I do is use a very simple hard fault handler that counts how often it happens, doesn't result in a loop and recovers (if it is a 'real'/serious hard fault it results in a hard fault interrupt loop anyway, which is very easy to debug as you just need to connect with a debugger and you see the exact code that is faulting (over and over again)).


volatile unsigned long ulHardFaultCounter = 0;
// Serious error interrupts
//
static void irq_hard_fault(void)
{
    ulHardFaultCounter++;                                                // hard faults are often recoverable so we count how many were detected for statistical reasons
}


I can always check the counter value to see whether it does every occasionally happen. If I prefer to 'clean' it up so that it doesn't I just set a break point on the increment line, let it run and see exactly where it takes place and then, if I want, I can add a barrier instruction (or similar - eg. adding some other code before accessing usually works) to exclude it. Recoverable hard faults are however not really worth worrying about as they have no negative side effects (that I ever experienced).

Regards

Mark
Pages: [1] 2 3 ... 10