OMAP-L137 : my day after ‚Hello World’ was a rainy day ...

Franz,

Did you try building your application as a subproject along with the OSDesign?  You can refer to the subproject StartupApp in the osdesign OMAPL137_AM17X_TI_DEFAULT as an example.  For your app, you might need to add more include paths in one of the subproject property tab.

Regards,

WM

Hi Franz,

I guess including bsp.h and each and every BSP specific files is not ideal way.

If I have to glow a LED from Application. Check how GPIOs are accessed in the BSP. If GPIOs access is implemented as a stream interface driver then you have to make some GPIO IOControls, to on or off the LED which is nothing but making GPIO either High or Low.

I think OMAP3530 BSP is implemented in a well organized way. May be you can use that for study purpose. or Else refer Bruce Eitman's Blog (http://geekswithblogs.net/BruceEitman/Default.aspx) which has several examples related to WinCE.

Just an example, Implement LED Driver as stream interface driver LED_Init, LED_DeInit, LED_Open, LED_Close, LED_IOControl.

In IOCONTROL API implement some IOCTL's such IOCTL_LED_ON, IOCTL_LED_OFF and etc...the definitions for these IOCTLs need to be present in SDK if you want to write an application based on SDK.

Now, use these IOCTL from application and turn them either on or off.

Also refer the following URL http://geekswithblogs.net/BruceEitman/archive/2010/08/01/windows-ce-using-a-driver-to-readwrite-hardware-registers.aspx 

Thank You & Regards,

GSR

Hi WMK,

I've tried building my app not as a subproject of the OS design but thanks for your hint to look at the StartupApp subproject of the OMAPL137_AM17X_TI_DEFAULT example; I'll do that very soon.

Instead I've been following the tutorial from Microsoft for writing native visual C++ apps (  https://www.microsoft.com/resources/virtuallabs/step1-msdn.aspx?LabId=e074297e-a825-4699-bb3e-dc1e7535257b&BToken=ex   ) where they advice that after having created an OS image to create a SDK , which then should be installed on the developers machines and then these developers can create WinCE apps running on the target device using that SDK . The advantage of this approach is that these developers do not need to have platformbuilder installed on their machines ! But as I've decribed in my former post this scenario does still not work for me.

Today I stepped back to the sample OS design 'OMAP_L137_AM17_SAMPLE' and created a very simple app called GPIOTEST2.CPP under the ..\TEST\APPS as shown in following picture:

The app reads the state of the USER-SW-1 DIP switch and prints it ( HIGH or LOW ) out to the debug output.

So finally my app GPIOTEST2 is now part of the osimage like all the other sample apps written by MPC DATA company.

The appplication now compiles and I can also run it on the target, but it  does not work properly because from the windows CE debug output i get always the string 'USER-SW-1 is HIGH although I change the state of this DIP switch to LOW before running this app :

134318 PID:24c000e TID:5bb0002 GPIO-test has been launched ....
 134320 PID:24c000e TID:5bb0002 USER-SW1 is HIGH
 134348 PID:24c000e TID:5bb0002 GPIO-test END

Any idea what I'm doing wrong here ? ( Is GPIO_8 of OMAP really connected to USER-SW-1 ? , Could you please test if you can run this program successfully on your EVM ? )

The disadvantage of this approach ( embedding the app inside the osimage ) is that after changing a small detail inside the source the whole image ( = nkbin.exe ) has to be created ( about 15 MB ) and downloaded to the target which takes about all in all 2 minutes on my system ( Platform builder still loads in the background the various symbols for many other OS modules when I already start my app ! ). Therefore I would prefer to work using Microsofts approach shown in above mentioned tutorial with the SDK. I am already able to build a Hello World WinCE app using the SDK based on the OSimage, can compile and download it ( using Active Sync over USB  = fine thing ! ) and run this app within less than 20s !

How do you develop your apps ?

Best regards,

Franz

Hi Franz,

I checked BSP_WINCE_ARM9_01_10_00\Test\TestPlan\"2902-TP01 TI Win CE 6.0 BSP for OMAP-L13x AM17x AM18x - Test Plan.pdf"  section 6.6 "GP
IO  Driver" and notice the following pre-requisites on testing GPIO:

• L137: UI board is not attached to the base board. LCD drivers, NAND driver and Notification LED driver are not included in the OS image.

The issue that you observed might be related to the pre-requisites which is a result of pinmux configuration.

The test code referred to in this section is under C:\TI\BSP_WINCE_ARM9_01_10_00\PLATFORM\OMAPL137_AM17X\SRC\TEST\CETK\GPIOTEST

WM

Hi WM,

thank you very much for your hints !

I've no UI board attached to my EVM but had to remove the LCD driver ( NAND - driver and Notification LED driver are already unchecked ) . Then I rebuilt the OS-image but now I get for the User-SW1 always LOW level, although I switch it back and forth.

I've done further analysis and have seen that when calling GPIOGetInputState() the function KernelIoControl(IOCTL_KERNELGPIO_COMMAND,..) is called and this function in my case always returns FALSE which resets the variable state (in file gpio.h) to 0 and therefore I always get LOW level for that pin.

To get more infomation what's going wrong I called function GetLastError() which returns the value 0x57 = ERROR_INVALID_PARAMETER.

What's going wrong with this simple program ? How can I read in the status of an input pin ? What am I missing to do ?

I would very much appreciate if you could try the following code on your machine/EVM and send me your results :

#include "stdafx.h"
#include "gpio.h"

void RetailPrint(wchar_t *pszFormat, ...)
{
    va_list al;
    va_start(al, pszFormat);
    vwprintf(pszFormat, al);
    va_end(al);
}

int WINAPI WinMain(HINSTANCE hInstance,
                     HINSTANCE hPrevInstance,
                     LPTSTR     lpCmdLine,
                     int       nCmdShow)
{
    RetailPrint(L"GPIO-test has been launched ....");

    // set direction of GPIO_8 pin = "USER-SW-1" to input
    GPIOSetDirection(GPIO_8, GPIO_DIRECTION_INPUT);

    if (GPIO_STATE_LOW == GPIOGetInputState(GPIO_8))
    {
        RetailPrint(L"USER-SW1 is LOW");
    }
    else
    {
        RetailPrint(L"USER-SW1 is HIGH");
    }
    RetailPrint(L"GPIO-test END");
    return 0;
}

With best regards,

Franz

Hi GSR,

thank you for your advice which I followed and built first a DEBUG build of the os image ( I'm astonished about the size which is now over 29MB ! )

Now the program worked as expected !

I could also set a BREAKPOINT in 'OALIoctlGPIOCommand()' in file gpio.c and the program stopped here. All goes right now !

Then I went back and created a RELEASE version of the os image and thought the error would occur again but this was NOT the case ! The program now works ! But this leaves a bad aftertaste because not knowing why something works is in my opinion as bad as not knowing why something does not work.

Nevertheless, best regards from

Franz

Hi Franz,

The DEBUG build image will be usually big. There is no need to surprise.

I guess, as you familiarize wince more and more you may understand why it worked in one case and why not in the other case.

All The Best,

Regards,

GSR