Page 1 of 1

MOD54415 PA0 and PA1

Posted: Fri Mar 08, 2019 7:40 am
by ephogy
I'm migrating an existing project from the MOD5272 to the MOD54415.
Initially I hacked on of our existing PCBs to reroute the pins that I needed into the correct locations. I did this for about 95% of the pins and then had a little test PCB made up that we could plug in.

for the last 2 pins, I arbitrarily picked PA0 and PA1 to drive a CMOS based mux to select different analog input sources.
Years ago, someone had ordered a MOD54415 rev 1.5 board, which I was using, and I could not trigger PA0/PA1. With a little searching on the forum I found a post suggesting the documentation was lacking here and suggested PA0/PA1 may not work as expected prior to rev ~1.8

I ordered a new board, Rev 1.10, and I now have control over PA0 and PA1.

First thing I noticed with this is that when I configure them to be GPIO pins, it breaks AutoUpdate.
No biggie, as the work around simply involved returning the pins to their reset state:

Code: Select all

void InitializeHardware()
    //Reference input PA0,1
    J1[9].function(PINJ1_9_GPIO); // PA0 - GPIO -- LBS
    J1[10].function(PINJ1_10_GPIO); // PA1 - GPIO -- ABS

    // PA0,1 are BE1,0 which are fsr pins.  lowest slew rate has a rise time of 16ns, and fall time of 21ns
    sim1.gpio.srcr_fb1 = (sim1.gpio.srcr_fb1 & ~0x03) | 0x00;   // 'lowest' (0x00) slew rate.

    J1[9].drive(); // PA0 - output
    J1[10].drive(); // PA1 - output

    J1[9] = 0;
    J1[10] = 0;

void ShutdownHardware()
    J1[9].function(PINJ1_9_FB_BE1); // PA0, PA1 as GPIO will cause the update programs to fail and corrupt the firmware.

    sim1.gpio.srcr_fb1 |= 0x03;   // 'highest' (0x03) slew rate.

So no biggie here.

I thought perhaps the slew rate was the issue, hence the configuration, but it doesn't appear to make an obvious difference.

However, very occasionally I'll see 'spikes' in my recorded data. By very rare, it was 3 over the course of 12 hours last night, and I get a sample every 10 seconds, so roughly 0.1% of my data is bad. In the lab, it's obvious, in the field is another story. To me, it appears as though the spikes in my data are caused by the MUX not switching when PA0 and PA1 are supposed to be toggled. These are toggled every 250ms. 0x00, 0x01, 0x10, repeat.

I don't see these spikes on the MOD5272 (there I'm using PA0 and PB7 due to this being added later on in the life cycle of the hardware) on the same PCB setup (I've simply removed my break out board to compare)

I think my next step would be likely to try it on two other pins, but before I go hacking my test PCB, I was wondering if anyone has any insight?


Re: MOD54415 PA0 and PA1

Posted: Mon Mar 11, 2019 6:44 am
by ephogy
Seems like it might have been a race condition on my side.

The MOD5441X code uses the SetPinIrq on IRQ2 which has a priority of 0x2200
the MOD5272 code assigned the interrupt handler, and had the priority set to 0x2700.

I ripped the 'interrupt' handler code out and placed it into a task as well, which is probably a better way to do it anyway.

Just to add to the above data sheet shortcomings on PA0 and PA1, the documents list J1[9] as PA0, and J1[10] as PA1, however, the code in pins.cpp:

Code: Select all

            case 9:
               #ifdef ENABLE_BE2_BE3
               sim1.gpio.ppdsdr_a = 0x04;
               sim1.gpio.pddr_a |= 0x04;
               sim1.gpio.ppdsdr_a = 0x02;
               sim1.gpio.pddr_a |= 0x02;
               #endif // ENABLE_BE2_BE3
            case 10:
               #ifdef ENABLE_BE2_BE3
               sim1.gpio.ppdsdr_a = 0x08;
               sim1.gpio.pddr_a |= 0x08;
               sim1.gpio.ppdsdr_a = 0x01;
               sim1.gpio.pddr_a |= 0x01;
               #endif // ENABLE_BE2_BE3
Seems to be toggling J1[9] as PA1 and J1[10] as PA0 and this seems to match the hardware behaviour.

Re: MOD54415 PA0 and PA1

Posted: Mon Mar 11, 2019 3:19 pm
by pbreed
Between version of the cold fire, freescale changed what PA0 and PA1 meant.
So inorder for external hardware busses to work in a compatible way between differnt
Netburner modules we made a modification...

In general I would use the bus related signals as a last resort for GPIO....
An if doing a PCB would add and I2C pin expader chip as best solution to more GPIO.