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 20 Dec 2004 02:17 PM by  mikea@logicpd.com
Possible CPLD BUG: LEDs vs. PCMCIA
 12 Replies
Sort:
You are not authorized to post a reply.
Author Messages
tom@cyberiansoftware.com
New Member
New Member
Posts:


--
13 Dec 2004 06:34 AM
    There is a problem with using the LEDs when the PCMCIA is disabled. When PCMCIACON == 0 then you cannot program the LEDs via the CPLD. This is true of a standalone program or from a program running under LOLO. Here is a working example showing the problem, there are four files:
    demo.h
    #define BOOTABLE 1
    #define USEPCMCIA 0

    demo.lds.S
    #include "demo.h"
    ENTRY(StartUp)
    SECTIONS
    {
    #if BOOTABLE
    . = 0x00000000;
    #else
    . = 0x000C0000;
    #endif
    .boot : { *(.boot) }
    .text : { *(.text) }
    .data : { *(.data) }
    .rodata : { *(.rodata*)
    . = ALIGN(4);}

    _text = ADDR(.text);
    _etext = ADDR(.rodata) + SIZEOF(.rodata);

    . = ALIGN(4);
    .bss : { *(.bss) }
    _bss = ADDR(.bss);
    _ebss = ADDR(.bss) + SIZEOF(.bss);

    . = ALIGN(4);
    }

    demo.S
    #include "demo.h"
    ;
    .global StartUp
    ;
    #if BOOTABLE==1
    .section .boot
    .word StartUp
    #endif
    ;
    #define rADDR r1
    #define rDATA r2
    ;
    #define rPGADDR r1
    #define rPGDATA r2
    #define rLEDADDR r3
    #define rLEDDATA r4
    ;
    .text
    .code 32 /* We are _not_ compiling thumb instructions. */
    ;
    StartUp:
    nop
    bl SetupPCMCIA
    bl SetupGPIO
    ldr rPGADDR, GPIO_DATA_G //init the Port G bit0 high.
    mov rPGDATA, #1
    str rPGDATA, [rPGADDR]
    ldr rLEDADDR, LED_ADDR //turn one LED on.
    mov rLEDDATA, #6
    strh rLEDDATA, [rLEDADDR] //set new LED pattern.
    ;
    Shifter:
    ldrh rLEDDATA, [rLEDADDR]
    eor rLEDDATA, rLEDDATA, #0xff
    mov rLEDDATA, rLEDDATA, lsl #1
    ands rLEDDATA, rLEDDATA, #7
    moveq rLEDDATA, #1
    NoReload:
    eor rLEDDATA, rLEDDATA, #0xff
    strh rLEDDATA, [rLEDADDR] //set new LED pattern.
    eor rPGDATA, rPGDATA, #1
    str rPGDATA, [rPGADDR] //toggle PG0.
    bl Delay //wait a while.
    b Shifter //keep wiggling the bits.
    ;
    SetupPCMCIA:
    ldr rADDR, PCMCIACON //setup PCMCIA.
    #if USEPCMCIA==1
    mov rDATA, #3 //allow for two PCMCIA cards.
    #else
    mov rDATA, #0 //allow Port G & H to funcion as GPIO.
    #endif
    str rDATA, [rADDR]
    mov pc, lr
    ;
    SetupGPIO:
    ldr rADDR, BCR7_REG //Point to BCR7.
    ldr rDATA, BCR7_DATA //get value to put in BCR7.
    str rDATA, [rADDR] //now set CS7 parms via BCR7.
    ldr rPGADDR, GPIO_DATA_DIR_G //set PortG as outputs.
    mov rPGDATA, #0
    str rPGDATA, [rPGADDR]
    mov pc, lr
    ;
    Delay:
    #if BOOTABLE==1
    mov r6, #0x8000
    #else
    mov r6, #0x80000
    #endif
    Delay_More:
    subs r6, r6, #1
    bne Delay_More
    mov pc, lr
    ;
    LED_ADDR:
    .word 0x71600000
    GPIO_DATA_DIR_G:
    .word 0x80000e38
    GPIO_DATA_G:
    .word 0x80000e3c
    BCR7_REG:
    .word 0x8000201c
    BCR7_DATA:
    .word 0x1000b2c2 //16bit, WST2=WST1=22, Idle=2.
    PCMCIACON:
    .word 0x80002040
    PINMUX_REG:
    .word 0x80000e2c

    Makefile
    PROG_PREFIX=arm-linux-
    ASFLAGS += -mcpu=arm9
    CFLAGS += -mcpu=arm9 -mlittle-endian -Werror -O2 -Wall -fno-builtin
    CC=$(PROG_PREFIX)gcc
    AS=$(PROG_PREFIX)as
    CPP=cpp
    OBJCOPY=$(PROG_PREFIX)objcopy
    INCLUDES=demo.h

    OBJS=demo.o

    default: demo

    all: clean demo

    demo.o: demo.S $(INCLUDES)
    $(CC) $(ASFLAGS) -c -o $@ $<

    demo: $(OBJS) $(INCLUDES) demo.lds demo.S
    $(CC) -nostdlib -o demo -T demo.lds $(OBJS)
    $(OBJCOPY) -O binary --strip-all demo demo.bin

    demo.lds: $(INCLUDES) demo.lds.S
    $(CPP) -P -Ush demo.lds.S | grep -v ^$$ > demo.lds

    clean:
    -rm -f *~ $(OBJS) demo demo.bin demo.lds


    I happened to stumble onto this while working with the LH7A400 in learning the assembler. The object is to have the three LEDs strobing sequentially while toggling PortG_bit0.

    To build & run:
    A. By setting BOOTABLE to 0 (zero), you can make a program to exec under lolo. Build it with 'make', burn 'demo' into flash, then 'exec 0xc0000 -'. By alternately setting USE_PCMCIA to 0/1 (zero / one), you will alternate between toggling PG0 or the LEDs, however you cannot do both.

    B.By setting BOOTABLE to a 1 (one), you will now make a binary image that can be place into Flash, replacing bolo. The file you need to burn would be 'demo.bin'. Place it in Flash starting from location 0x0000:0000.

    Note: You may have to change PROG_PREFIX and / or the "-mcpu=arm9", in Makefile, to match your compiler.
    ---
    tom@openhardware.net
    Anonymous
    Posts:


    --
    17 Dec 2004 01:01 PM
    TomW,

    Can you provide a bit more information for what you're doing? While Linux can be ported, and has been for many customers, to the LH7A400-10 card engine there is work that would need to be done to make it production ready. With this in mind there are probably issues with the source from Sharp's website and probably shouldn't be attributed to a bug in the CPLD.

    Regards,
    tom@cyberiansoftware.com
    New Member
    New Member
    Posts:


    --
    17 Dec 2004 03:56 PM
    This is not a linux port issue. The target environment is to port a current proprietary system from an 80188 environ to the ARM922T (LH7A400). This system does not use an O/S, per se, but one that we have written for this product.

    The concern is that the CPLD is interfered with with the need to turn on the PCMCIA. We have no need for PCMCIA operation as the plan is to deeply embed the LH7A400-10 inside the unit. However we do need the use of the GPIO.

    I think that the code examples that I have provided clearly demonstrate that this issue is solely within the CPLD? The issue is that an internal register (latch) is being written inside the CPLD, why should PCMCIA need be enabled to do this? It appears to me that there is a specific relationship between a PCMCIA control line and that of the Extended_GPIO_Resister in your VHDL design file for the CPLD. If this is intentional, then why is that not documented in your "LH7A400-10 Card Engine IO Controller Specification"??

    From the documentation, schematics, etc., there is nothing that indicates that this should be a problem. The doc "LH7A400-10 Card Engine IO Controller Specification" makes no mention that the 'Extended GPIO Register' is other than 'General Purpose'.

    My opinion is that this was intentional, that the LEDs were to be used to indicate the card presence?
    mikea@logicpd.com
    New Member
    New Member
    Posts:


    --
    20 Dec 2004 09:52 AM
    TomW,
    I don't believe there is an issue with the CPLD. I can base this on a simple test in LogicLoader.

    (Please keep in mind during this test that LogicLoader toggles the LEDs ever second or so...you must watch quickly)

    losh> w /h 0x71a00000 0x06 //This will disable PCMCIA/Enable uP GPIO
    losh> w /h 0x71600000 0x00 //This will turn on all 3 LEDs at once
    losh> w /h 0x71600000 0x0f //This will turn off all 3 LEDs at once


    There is no connection between the Extended GPIO Register and the PCMCIA control lines in the VHDL code. Please be sure your code is always doing 16 bit writes/reads when accessing the CPLD register. Also, do you know if you have the most up to date CPLD code? If the card engine has been on the disty shelf for awhile before you got it, the CPLD code may be very old.

    Hopefullly this helps, I'll be interested in what you find.
    Thanks,
    Mike
    tom@cyberiansoftware.com
    New Member
    New Member
    Posts:


    --
    20 Dec 2004 10:52 AM
    Ok, this was recently purchased from DigiKey. What version CPLD code should I be using, and how do I check that? I have "CPLD_CE_REG_REVISION: 0x37 (rev: b)"

    Respectfully, I think that you completely missed the point. The point is when all LPD software is out of the system, and you boot the Card Engine from a custom application (which replaces bolo), you cannot control the LEDs unless you first enable the PCMCIA.

    There is no bolo, there is no lolo software in this system. Nada, the only thing running is the application which I outlined above. This application is what the controller will boot. Please note the ".section .boot".

    The application clearly demonstrates a collision, or dependancy upon, the presence of PCMCIA control signals (clocks?) that the CPLD has before it will accept data written into the CPLD.

    Please note, that the program outlined does, in fact, use 16bit writes.
    tom@cyberiansoftware.com
    New Member
    New Member
    Posts:


    --
    20 Dec 2004 11:31 AM
    Well, that certainly worked really well... <!-- s:-( -->:-(<!-- s:-( --> I updated the CPLD to version 3E and it broke the JTAG flash programmer. I am no longer able to write a value into 0x71000000.

    Where can I find the CPLD update for 37? I would rather have a broken CPLD than one that is unusable.

    BTW, I ordered the LH79520 Zoom kit the other day, I hope that I have better success with that kit than I have had with the LH7A400-10

    Problems I've enountered so far, that have been show-stoppers:

    1. JTAG programming of the Flash, on the LH7A400-10 the CPLD has a lot of difficulty accepting a value into 0x71000000. Several initialization attempts have to be made (RESET board, run JTAG, write a value, read it back) before the CPLD will accept a VPEN bit setting.

    2. Apparent collision between CPLD operation of the LED register and the PCMCIA.

    I would like to get beyond these issues and start coding my application so that I can show the customer the Concept design.

    I cannot see why I am having so much trouble with the JTAG, this is a industry standard, I have used this before on the Intel SA1100 without problems. Others I have contacted, are using LH79520 designs and programming the boards, plus doing debug work via JTAG, have not reported these types of problems.

    I guess that I will have to wait for the LH79520 Zoom kit to see where the problem lies. Whether the JTAG host software is at fault or if it lies in the LH7A400-10 design.

    I'll let you know what I find, but I really need that CPLD 37 file?
    mikea@logicpd.com
    New Member
    New Member
    Posts:


    --
    20 Dec 2004 11:35 AM
    I do realize your code is not using Logic software, my example was an easy way for me to say, I have the PCMCIA control off and I can toggle the signals that are connected to the SDK LEDs.

    The most updated CPLD code can be found on the download site. It is found under the Logicloader section and is called the "LH7A400-10 CPLD Update". The most recent version is 3.E. You must have created an account on our website and registered the kit to get access to this page.

    Let us know if this helps,
    Thanks,
    Mike A.
    tom@cyberiansoftware.com
    New Member
    New Member
    Posts:


    --
    20 Dec 2004 12:00 PM
    From what I can tell, I programmed the example code into 0xc0000 via lolo and then "exec 0xc0000 -", the problem still exists. You have to have the PCMCIA enabled to affect a change on the LEDs.

    Can I get the CPLD version 3.7 code binary (the upd file)?
    mikea@logicpd.com
    New Member
    New Member
    Posts:


    --
    20 Dec 2004 12:18 PM
    TomW,
    I don't see where you are disabling the CPLD use of the PCMCIA signals and enabling use of the Port G and Port H GPIO in your code. This is done in register 0x71A00000. (Bit 1) Please read the CPLD PCNs, for each CPLD version update information. PCN 239 has infor about the PCMCIA use.

    Did you use the 'update' command in LogicLoader to update your CPLD?

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


    --
    20 Dec 2004 12:43 PM
    Yes, I updated via LOLO. "info version" now says:
    Version : 1.4.3-LLH7a400_10 0001
    Build : lpd077 Thu Jun 3 17:53:35 CDT 2004
    CPLD_CE_REG_REVISION: 0x3e (rev: b)


    As for the disable of PCMCIA, refer to the Sharp publication "LH7A400 System-on-Chip User's Guide"http://www.sharpsma.com/pub/productfocus/publications/micro/mcu/tec_usersguide_lh7a400.ZIP on page 100 (Section 4.2.2.5) it says that writing a value of 0 to bits 0 & 1 will disable the PCMCIA interface. Also refer to page 155 (Section 7.1.3.2) it states:
    Quote:
    The PCMCIA and CompactFlash (CF) PC Card support is multiplexed with the GPIO Ports G and H. To select PC Card or GPIO operation, set the PCMCIA Control register PC Cards 1 and 1 Enable fields (PCMCIACON:PC12EN), shown in table 7-5 (Also see Chapter 4 for more details).

    Also look to page 77 (Section 4.1.3.2)
    Quote:
    The PCMCIA and CompactFlash (CF) signals are multiplexed with GPIO Ports G, H, F6 and F7. To select between Card or GPIO opeation, and to configure the system for one or two card (any combination of PCMCIA and CF Cards), set the PCMCIA control register PC Cards 1 and 2 Enable field (PCMCIACON:PC12EN[1:0]):
    00 diables both card, configuring ports G and H as GPIO.
    01 enables one card in CF mode at 0x4000:0000 (Slot 0).


    Since PCMCIACON is at 0x8000:2040, writing a value of zero at that location will disable the PCMCIA card operation.
    mikea@logicpd.com
    New Member
    New Member
    Posts:


    --
    20 Dec 2004 12:54 PM
    Yes, you are correct. You must set the PCMCIACON register in the LH7A400 correctly. But, you must also set up our CPLD correctly so that it ignores the PORT G/H/ PCMCIA signals. On reset, the CPLD thinks that these signals are PCMCIA signals and thus if you set them up as GPIO signals, the CPLD still thinks they are PCMCIA and thus will lock up the system. Please read the PCN I specified for more information.
    tom@cyberiansoftware.com
    New Member
    New Member
    Posts:


    --
    20 Dec 2004 01:46 PM
    AH! Finally. This has been exactly the point that I have been trying to make and get you to admit to: that there is an undocumented relationship between the functionality of one area of the CPLD and another. Of which, remains undocumented in the "LH7A400-10 Card Engine IO Ctonroller Specification", your P/N 70000079.

    Now for the $64,000.00 question: How do the LEDs become dependant upon the settings of the PCMCIA ??? No, no, no, let's not say anything about bolo, lolo, or logic loader, just from the standpoint of a custom application running in the Flash, e.g. no Logic Products Development software anywhere in the system.

    Second question, as I already know the answer to question #1, just want to hear you say it (that the LEDs are used by the CPLD to indicate card ativity, enabling PCMCIA operation overrides the use of the Extended GPIO Register @ 0x71A0:0000). Here is the second question: Why is this not documented ???

    Now this whole excercise may sound mean-spirited and silly. Keep in mind that we intend on porting an exsisting product from an 80188 CPU over to the LH7A400 (or similar ARM9 CPU). This application has been developed over a 22 year span and is a proprietary system. Having undocumented operation of that CPLD is not something we need.

    Here is my point, I spent three days narrowing in on why the LEDs could not be controlled from software. All documentation said that they could be, both the LPD and Sharp manuals. I accidentally stumbled upon the answer by looking at the J39 connector for a convient place to hang a scope lead. That is when I discovered that I could not toggle a Port G pin.

    Not being able to toggle a Port G pin is not the issue. That was explained by reading the Sharp manual and it disclosed that the PCMCIA used that pin. So, by accident, when I programmed the PCMCIA on within the processor, I suddenly had control over the CPLD and could set the LEDs.

    Why are the LEDs an issue? Simply this: It is not documented.. Hence, a lowering of confidence in using the LH7A400-10. The question is, if it took me 10 days to resolve this issue with the LEDs (3 to locate the problem and 7 to get LPD to admit it), what other problems am I going to encounter with the undocumented CPLD?

    IMHO, the biggest mistake LPD has done is to put the CPLD on the board and then not have adequate documentation, or, a VHDL file for people to read. I'm considering canceling the order for the LH79520 engine and getting the Revely board for that part of our project.
    mikea@logicpd.com
    New Member
    New Member
    Posts:


    --
    20 Dec 2004 02:17 PM
    TomW,
    The LEDs are not dependent on the PCMCIA control. If the PCMCIA control is not disabled in the CPLD before switching the GPIO G and H pins to GPIO, the CPLD will lock up. So, it may seem the LEDs are tied to the PCMICA, this is not true. The entire CPLD is in a lockup state. The CPLD uses the PCMCIA control signals to enable the use of Dual Slot, etc. When these signals are put into a GPIO state, the CPLD thinks it is still in PCMCIA mode and gets into a lock-up state. To answer your question, the LEDs are not tied to any PCMCIA activity.

    The use of PCMCIA control for the CPLD is documented in PCN 239, the I/O controller spec (rev E.), and Whitepaper 264. Any changes to CPLD code, etc. are documented in PCNs describing the changes and are included in updated I/O Controller specs. Also, any documentation updates are sent out via an email to those who have registered kits. The TDG is a great place to search for information. You will find that there are a couple of Topics on this exact discussion.
    http://www.logicpd.com/su.../viewtopic.php?t=340
    http://www.logicpd.com/support/tdg/viewtopic.php?t=161

    I think you will find that the LH7A400-10 has quite a bit of documentation and anything we find, we try to get to the customer in the best way possible.

    Thank You,
    Mike A.
    You are not authorized to post a reply.