MOD54415 DEV-70 R1.7 LED's

[GeneralUser]

Sorry if this is a basic question, but using v1.7 MOD54415, how do I turn on all the LEDs? According to the schematics (which say 1.6 by the way), the LEDs are:
J2[15] = LED1
J2[16] = LED2
J2[18] = LED3
J2[23] = LED4
J2[17] = LED5
J2[19] = LED6
J2[20] = LED7
J2[24] = LED8

This cannot be right because the MOD54415 datasheet shows, for example, that J2[17 and 18] are inputs only - USB+/USB-....I also do not see all the LED's turn on using the above pin-out either so that confirms it. The only LED's that work are LED1, LED2, LED6 and LED7....Odd thing too is when I do a continuity test to my board, the pin-out above truly does look correct but again, I am confounded because the datasheet says that 17 and 18 are inputs only....
What am I missing?

[Ridgeglider]

Take a look at C:\nburn\MOD5441X\include\pinconstant.h at the configurations for J2[17] and J2[18] which indicate that they can be configured as GPIO. Not sure if there is an input-only restriction on this part, but it would be easy to test.
This call should write all 8 led lines to turn on the leds: putleds(0xFF);
turn of all 8: putleds(0);

I seem to remember that the LEDs on the dev70 board are wired so writing a 0 to the port turns them on, but putleds() inverts the logic internally so putleds(0) turns all LEDs off.

[GeneralUser]

Odd, every 1.0 second, I call putleds and toggle the values (0xFF to 0x00) and not a single LED comes on ever.
Only way I was able to turn on the 4 LED's is by direct control; J2[pin] = 1.

[rnixon]

If you do a search for putleds() in the \nburn\system folder there is a note in my release that says its deprecated. Which makes sense because you wouldn't want this to happen in a final product since those signals could be connected to something that would cause bad behavior if toggled. So do not use putleds(), use the pins class instead.

Second item. There is a PCN on the MOD54415 about a pin change on signals 17 and 18 of J2. They can no longer be used as GPIO since they USB feature does not allow it. The MOD-DEV-70 board is used for multiple modules, so in the case of the MOD54415 there seems to be a conflict with those two signals. If you want to make them work, one way would be to cut the traces for J2 17 and 18, and jumper some other GPIO signals to those LEDs.

[dciliske]

To clarify the issue of pins J2[17] and [18]: These pins have been reassigned to the USB module and cannot be accessed as normal GPIO. However, it is possible to use them as inputs, by reading out of the USB hardware registers.

[Ridgeglider]

This code works. WriteLeds is from the factory demo. Not sure why putleds() does not work?

Code: Select all

#include "predef.h"
#include <stdio.h>
#include <ctype.h>
#include <startnet.h>
#include <autoupdate.h>

#include "pins.h"

extern "C" {
void UserMain(void * pd);
}

const char * AppName="Mod54415_leds";

/*-------------------------------------------------------------------
 * On the MOD-DEV-70, the LEDs are on J2 connector pins:
 * 15, 16, 18, 23, 17, 19, 20, 24 (in that order)
 * -----------------------------------------------------------------*/
void WriteLeds( BYTE LedMask )
{
   static BOOL bLedGpioInit = FALSE;
   const BYTE PinNumber[8] = { 15, 16, 18, 23, 17, 19, 20, 24 };
   BYTE BitMask = 0x01;

   if ( ! bLedGpioInit )
   {
      for ( int i = 0; i < 8; i++ )
         J2[PinNumber[i]].function( PIN_GPIO );
      bLedGpioInit = TRUE;
   }


   for ( int i = 0; i < 8; i++ )
   {
      if ( (LedMask & BitMask) == 0 )
         J2[PinNumber[i]] = 1;  // LEDs tied to 3.3V, so 1 = off
      else
         J2[PinNumber[i]] = 0;

      BitMask <<= 1;
   }
}


void UserMain(void * pd) {
    InitializeStack();
    OSChangePrio(MAIN_PRIO);
    EnableAutoUpdate();


    iprintf("Application started\n");
    BYTE count = 0;
    while (1) {
        OSTimeDly(1);
       WriteLeds(count++);
        iprintf("count = %d\r\n", count);
    }

[GeneralUser]

Thanks for the insight.....So yes, the WriteLeds() function does work but since the USB now uses J2, pins 17 and 18, LED3 and LED5 can no longer be used as outputs...

[Ridgeglider]

True if you really need native USB support, but to my knowledge no NB firmware supports the native USB ports on the uC yet....

As clarification, there is USB to serial support on the Dev boards, but this uses the standard uC serial COM ports and simply converts them to USB_serial using a separate IC. If you are indeed using the native Coldfire USB hardware I suspect many of us would be interested in the USB code you're running... FYI, the schematics for the Dev70 and Dev100 boards show the connections to the standalone USB/Serial driver IC. See C:\nburn\docs\Platform\Schematics for more info.