Search

Technical Discussion Group Forum

This forum is provided for user discussion. While Beacon EmbeddedWorks support staff and engineers participate, Beacon EmbeddedWorks does not guarantee the accuracy of all information within in the Technical Discussion Group (TDG).

The "Articles" forums provide brief Articles written by Beacon EmbeddedWorks engineers that address the most frequently asked technical questions.

To receive email notifications when updates are posted for a Beacon EmbeddedWorks product download, please subscribe to the TDG Forum of interest.

TDG Forum

PrevPrev Go to previous topic
NextNext Go to next topic
Last Post 12 Dec 2004 11:15 PM by  tom@cyberiansoftware.com
LEDs on SDK
 14 Replies
Sort:
You are not authorized to post a reply.
Author Messages
James Zipperer
New Member
New Member
Posts:


--
03 Aug 2004 06:38 PM
    Are the LEDs (GPIO01/STATUS_LED0/STATUS_LED1) controllable through software? According to the schematic, they aren't hooked up to GPIOs on the processor. That is, unless I'm on crack. I see they are hooked up to the CPLD, but can't find any info about controlling them through the CPLD.

    Thanks.
    Andreas
    New Member
    New Member
    Posts:


    --
    04 Aug 2004 10:27 AM
    Hello James,

    Recreational drugs are incredibly helpful when dealing with Windows CE, it is however frowned upon by my employer so I use this method of controlling LEDs:

    Assuming you use eVC++ to build your application, and this is a Win CE project:

    include these files,
    #include <mmsystem.h>
    #include "CEDDK.h"

    then in your application use the virtual memory mapping functions to get a handle to the physical memory address of the CPLD:

    PHYSICAL_ADDRESS IOControllerAddr;
    PUCHAR IOControllerBase;
    // get the GPIO register address from Logic's IO Controller Interface Spec
    IOControllerAddr.LowPart = 0x71600000;

    // get a handle to virtual memory and the 16 bytes following the base address
    IOControllerBase = (PUCHAR)MmMapIoSpace( IOControllerAddr, 0x10, false);

    // now you can read or write to the virtual memory handle
    *(volatile PUCHAR)(IOControllerBase) = 0x00;
    *(volatile PUCHAR)(IOControllerBase) = 0x03;

    Now you need to include the ceddk.lib library provided on Logic's download area into your application.

    Step through and observe....nothing happening. I believe when debugging the application, the LEDs are hijacked by debugger software. Maybe this method works in a release build without debugging.

    I can use the method above to for example read the Revision register in the IO controller so assuming method is correct.

    So, in my system, I hooked up some spare GPIO pins to LEDs on a breadboard, see chapter 16 in the Sharp ARM manual for addresses. Now use the method above for controlling the GPIO of your choice.

    merry soldering,

    Andreas
    James Zipperer
    New Member
    New Member
    Posts:


    --
    04 Aug 2004 11:45 AM
    Thanks for the help.

    Finally found the where the 0x71600000 is coming from, it's in the IO Controller Spec.

    I observe the same inactivity of the LEDs as you do through your c program when trying to make them light up through losh. I've tried writing the register as a word, half-word and byte and nothing.

    -James
    mike tesch
    New Member
    New Member
    Posts:


    --
    05 Aug 2004 05:12 AM
    losh generally takes over LED control, but when it does, they should be blinking.

    mt
    mikee@logicpd.com
    New Member
    New Member
    Posts:


    --
    10 Aug 2004 01:38 PM
    Gentlemen,

    Within CE, the LED's get twiddled by the OAL. One comes on when the processor is running, the other comes on when OEMIdle() is called. That is to say, when the processor is in sleep mode because the kernel doesn't have any threads to run.

    If you need access to these particular LEDs, you should contact our support group and they can probably build you an OAL that doesn't use them.

    Regards,

    --mikee
    James Zipperer
    New Member
    New Member
    Posts:


    --
    25 Oct 2004 11:29 AM
    Still having some trouble with the LEDs on the SDK. I can set/clear the GPIOs just fine under losh, but it doesn't work when I'm running eCOS. I'm trying to toggle GPIO01 every 100ms. Instead of GPIO01 toggling, both GPIO01 and STATUS LED1 turn on solid and won't turn off.

    Is there some sort of CPLD initialization sequence that has to be done? All I did to set up the CPLD was set up SMC Bank7 like it is when losh is running: 0x8000201c = 0x1000fbe0.

    I'm using a barrier function to access CPLD registers, like the one described in AppNote 175 (Interfacing to the On-board ADS7843 Touch Controller). It doesn't seem to help.

    My CPLD code revision register reads 0x34.

    Any other ideas? My ultimate goal is to get the touchscreen interface in the CPLD working, but since I can't even toggle an LED, I'm starting there.

    Thanks.
    mikee@logicpd.com
    New Member
    New Member
    Posts:


    --
    25 Oct 2004 11:43 AM
    James,

    There is no initialization sequence for the CPLD that I am aware of. Code should look something like this:


    void
    toggle_leds_one_way(void)
    {
    volatile unsigned short tmp;
    volatile unsigned short *reg;
    reg = (volatile unsigned short *)(0x71600000);
    tmp = *reg;
    barrier();
    tmp &= ~2;
    tmp |= 1;
    *reg = tmp;
    barrier();
    return;
    }

    void
    toggle_leds_the_other_way(void)
    {
    volatile unsigned short tmp;
    volatile unsigned short *reg;
    reg = (volatile unsigned short *)(0x71600000);
    tmp = *reg;
    barrier();
    tmp &= ~1;
    tmp |= 2;
    *reg = tmp;
    barrier();
    return;
    }


    Can you read from the CPLD? That is to say, looking at the I/O controller specification, can you read registers defined in the CPLD and see sane, initial values?

    Let me know if this helps.

    Regards,
    --mikee
    James Zipperer
    New Member
    New Member
    Posts:


    --
    25 Oct 2004 12:08 PM
    The CPLD revision register reads back:
    0x71400000 = 0x2034.

    Is that reasonable?

    While it's toggling, GPIO register reads back:
    0x2034
    0x2004
    0x2034
    0x2004
    ....

    That doesn't seem reasonable.

    -James
    James Zipperer
    New Member
    New Member
    Posts:


    --
    25 Oct 2004 12:33 PM
    What does your barrier function look like? I think the problem has something to do with that. Here's mine:


    void barrier(void)
    {
    volatile unsigned int tmp = *(volatile unsigned int *) 0x04100000;

    chumpier_tmp = 1;
    }


    0x04100000 is the base address of flash. I've tried switching around the address to other uncacheable addresses and it changes the results of the reads from CPLD memory, but the results of the reads still aren't right.

    Does the barrier function need to toggle both WE and CS?

    -James

    James Zipperer
    New Member
    New Member
    Posts:


    --
    26 Oct 2004 03:53 PM
    I checked CS7 on an oscilloscope and it's toggling, so I'm not sure what the problem is. Are there some CPLD timing requirements I'm missing?

    I notice that when lolo runs, it sets BCR7 (0x8000201c) to two different values as lolo boots:

    0x8000201c = 0x1000b2c2
    0x8000201c = 0x1000fbe0

    Using either of these two values doesn't improve my situation. Any ideas?

    -James
    Anonymous
    Posts:


    --
    27 Oct 2004 03:22 PM
    It looks like your function is using 32bit access. This would immediately overwrite 0's into the low byte after you wrote the value you intended.
    Make sure you use a 16 bit pointer when you access the cpld registers.
    mikee@logicpd.com
    New Member
    New Member
    Posts:


    --
    28 Oct 2004 02:28 PM
    James,

    Did Bruce's comment help you out?

    Thanks,
    --mikee
    James Zipperer
    New Member
    New Member
    Posts:


    --
    01 Nov 2004 05:30 PM
    No, it didn't help out. Thanks for the follow up. I've tried 8, 16, and 32 bit access none of them work. I'm not sure what else to try, so suggestions are welcome. Could you share your barrier() function with me?

    I'm working another project (non LH7A400) this week, so the Sharp world has been put on hold.

    -James
    mikee@logicpd.com
    New Member
    New Member
    Posts:


    --
    01 Nov 2004 05:47 PM
    Here it is.


    /* Function to do a read from the base of flash. This will
    * toggle our external chip-select lines correctly on the
    * A400 part.
    *
    * Note, the only reason that this returns a value at all is
    * that I get _very_ paranoid that the compiler might
    * optimize it out.
    */
    __inline__ volatile unsigned short
    barrier(void)
    {
    volatile unsigned short *flash_base;
    volatile unsigned short bogus;

    /* Note, on our systems, an un-cached access to
    * flash can be done at 0x0. This might vary for
    * you depending on how you are setting up the
    * MMU. */
    flash_base = (volatile unsigned short *)0x0;
    bogus = *(flash_base);
    return (bogus);

    } /* end barrier() */


    I assume that it is just as you have it implemented. Something else must be wrong. Perhaps your MMU setup.

    --mikee
    tom@cyberiansoftware.com
    New Member
    New Member
    Posts:


    --
    12 Dec 2004 11:15 PM
    Posted By brucer on 27 Oct 2004 3:22 PM
    It looks like your function is using 32bit access. This would immediately overwrite 0''s into the low byte after you wrote the value you intended.
    Make sure you use a 16 bit pointer when you access the cpld registers.




    Refer to BCR7 (address 8000:201c). BOLO / LOLO configures CS7 to be: 16BIT, WST2=WST1=22, IDLE=2. Therefore, writing a word to the CPLD (using CS7) would result in two, successive, half-word writes. Not only would you need to ensure that you write half-words to an location within the CS7 range, but you also need BCR7 properly setup.

    Although, just from reading the schematic, it would appear that a 32bit write would result in 24bits being "lost" (D8..D31), the CPU would "see" that that CS7 can only handle 16bits at a time. To satisfy the 32bit transfer, the CPU microcode would perform two successive write operations, one for each half-word. This effectitvely writes two halfwords at the same location within the CPLD.

    Note: Also see my post regarding the conflict between PCMCIA + LEDs. This appears to be an issue with the CPLD, you need to enable at least one PCMCIA interface via PCMCIACON before you can properly program the LEDs within the CPLD register.
    You are not authorized to post a reply.