| 13 Jan 2005 03:28 AM |
|
|
I am starting to modify the foo driver to work with the board timer interrupts rather than the GPIOs.
Is there any issue with that?
Is the windows multimedia timer (1ms) already using one of those timers?
It seems that I need to change the interrupt from 0x05 (GPIO) to 0x08 (timer1). Anything else obvious?
I noticed that my kernel is version a400_50_2_1_2_0 but the Sample dev image is using a400_50_2_1_3_0. It would be nice to be able to get some more details on how the sample dev image was built, I have a hard time building one that does not cross the ROM limit when I try to just match the description in Sample Dev Image Rev B Release notes.
Thanks,
Luc
|
|
|
|
| 16 Jan 2005 04:46 AM |
|
I keep getting error 1 (ERROR_INVALID_FUNCTION) upon trying to load the dll. any idea why?
my loading code looks like this:
ApplicationStatus=0;loadError=0;
for (i=9; i>=0; i--) {
TestDevice = RegisterDevice(TEXT("FOO"),i,TEXT("lpd_LOCE_FOO.dll"),0);
if (TestDevice)
break;
};
if (TestDevice==0) {
loadError=GetLastError();
NKDbgPrintfW( TEXT("Robot App: RegisterDevice(lpd_LOCE_FOO.dll) failed %d\r\n"),loadError);
ApplicationStatus = 2;
}
else
{
ApplicationStatus = 1;
}
I also modified the FOO_Init to return quickly TRUE anot not care about the parameters.
Thanks,
Luc |
|
|
|
mikee@logicpd.com New Member Posts:  
| 18 Jan 2005 01:42 PM |
|
|
lucb,
I don't know why your driver is failing to load, our support team can probably help you out with that.
However, you must be aware of the fact that the kernel uses timer-1 for its system tick and timer-3 for a profile timer. Therefore, you need to only use timer-2 lest you mess up the kernel.
Regards,
--mikee
|
|
|
|
| 19 Jan 2005 08:14 AM |
|
|
I found the latest kernel. Doh.
I can now build an os image that runs including my device driver and its ISR. (As long as I do not enable the interrupts...)
Because the foo driver is in the image, it is launched at boot time.
Any hints on how to be productive in debugging in such an environment?
loading a new nk.bin on the cf everytime is not very effective.
I have not figured out how to debug yet (it seems I need to, to figure out why my interrupts kill me...)
Under eVC++ I should be able to attach the debugger to a WinCE process but instead I get the error: can't download the toolhelp.dll. Is that what I should try to solve?
Thanks,
Luc
|
|
|
|
mikee@logicpd.comNew Member Posts:
| 19 Jan 2005 10:10 AM |
|
|
lucb,
If you are building your own CE images using Platform Builder, then I highly recommend you also use Platform Builder to develop your device driver. You can use PB's kernel debugger which is actually quite nice to work with. We have a whitepaper on the website which should walk you through building a debug image and using the kernel debugger.
--mikee
|
|
|
|
| 19 Jan 2005 02:08 PM |
|
Thanks for the info.
Currently I am stuck with an error on
LoadIntChainHandler((LPCWSTR)isr_dll, (LPCWSTR)isr_handler, IRQValue); I get an error 87. bad parameter. I don't understand why
I tried 5 and 9 for the IRQ value. 9 for timer2.
the dll name is good. otherwise it gives error 126.
The problem must be the name of the isrhandler I suppose.
I am compiling the isr as a dll with:
/nologo /W3 /Zi /Od /I "C:\WINCE500\PUBLIC\COMMON\OAK\INC" /D WINCEOEM=1 /D NOLIBC=1 /D NOMIPS16CODE=1 /D "DEBUG" /D _WIN32_WCE=$(CEVersion) /D "ARM" /D "_ARM_" /D "$(CePlatform)" /D "ARMV4I" /D UNDER_CE=$(CEVersion) /D "UNICODE" /D "_UNICODE" /D "_USRDLL" /D "FOO_ISR_EXPORTS" /Fp"ARMV4IDbg/foo_ISR.pch" /YX /Fo"ARMV4IDbg/" /Fd"ARMV4IDbg/" /QRarch4T /QRinterwork-return /M$(CECrtMTDebug) /c
any clue on what could be wrong?
Thanks |
|
|
|
mikee@logicpd.comNew Member Posts:
|
| 20 Jan 2005 02:24 AM |
|
Yes I had been on it before.
Here is what solved the problem:
Looking at the Dll with a text editor I saw that I was not exporting ISRHandle.
Because I am building the ISR DLL with eVC++ I have to add the specific request to export:
DWORD __declspec(dllexport)
ISRHandler(DWORD instance)
I believe PB does it by using a isr.def file, but I did not figureout how to use the same.
Any way, now LoadIntChainHandler behaves well.
Onto the next problem....
thanks for the help. |
|
|
|
mikee@logicpd.comNew Member Posts:
| 20 Jan 2005 06:31 AM |
|
|
lucb,
You are very welcome. I'm glad that you fixed your problem and am sorry I couldn't help out more.
I want to thank you for taking the time to post the solution back here on the technical forums. We at Logic really appreaciate it when customers do that.
Best regards,
--mikee
|
|
|
|
| 20 Jan 2005 09:08 AM |
|
Thanks. Here is the next level problem.
I am trying to get the proper addresses to my ISR.
I have two sets to deal with. One for the timer2 to clear it.
The other to be able to communicate with my hardware.
BOOL GoodTransBusAddrToStatic = TRUE;
unsigned long dwMemSpace=1;
PHYSICAL_ADDRESS phy_addr;
phy_addr.LowPart = 0x80000c20;
phy_addr.HighPart = 0;
if (!TransBusAddrToStatic(Isa,
0,
phy_addr,
16,
&dwMemSpace,
(void**)&isr_info.PortAddr)) {
FOOMSG(ZONE_ERROR,
(TEXT("%s Install_ISR : Failed TransBusAddrToStatic(0x80000c20) : ErrorCode [%u]\r\n"), DRVR_NAME, GetLastError()));
GoodTransBusAddrToStatic = FALSE;
}
if (GoodTransBusAddrToStatic) {
dwMemSpace=1;
phy_addr.LowPart = 0x63000000;
phy_addr.HighPart = 0;
if (!TransBusAddrToStatic(Internal,
0,
phy_addr,
0x300,
&dwMemSpace,
(void**)&isr_info.PortAddr2)) {
FOOMSG(ZONE_ERROR,
(TEXT("%s Install_ISR : Failed TransBusAddrToStatic(0x63000000) : ErrorCode [%u]\r\n"), DRVR_NAME, GetLastError()));
GoodTransBusAddrToStatic = FALSE;
}
}
the first TransBusAddrToStatic works the seconds does not. but the error is 0!
in the same code, if I try :
PHYSICAL_ADDRESS phy_addr;
// sets the MMU to enable registers and address space for the Harwdare controls.
phy_addr.LowPart = 0x63000000;
phy_addr.HighPart = 0;
address_base63 = MmMapIoSpace(phy_addr, 0x300, FALSE);
that works!
What am I missing?
Thanks,
Luc |
|
|
|
| 20 Jan 2005 09:10 AM |
|
|
Just to clear the obvious, the length is not the issue, I tried 16. The bus type Internal versus Isa is not either. I tried Isa also.
Luc
|
|
|
|
mikee@logicpd.comNew Member Posts:
| 20 Jan 2005 09:15 AM |
|
|
The second call to TransBusAddrToStatic() uses 'Internal' as a parameter. Don't use that, stay with 'Isa.' I think this information was buried in that earlier post but I'll explain it again here.
Back in the early versions of CE 4.x, there was no 'Internal' type-specifier within the CEDDK. When Microsoft added it (I forget which release exactly), I don't think that I ever went back and added it into the code. So, the call is failing because it makes a call into the CEDDK and that code doesn't know what kind of translation to do with an 'Internal' bus type.
Since everything on these boards is memory mapped, the 'Isa' bus-type works for them all. Specifically, 'Isa' doesn't apply any translation to the physical address you pass in.
Hope that helps,
--mikee
|
|
|
|
| 20 Jan 2005 09:19 AM |
|
|
as mentioned above Isa fails the same way.
|
|
|
|
mikee@logicpd.comNew Member Posts:
| 20 Jan 2005 09:39 AM |
|
|
Does 'Isa' fail when using the smaller size? If it does, then I am afraid that I am stumped. If that is the case, I think you will need to contact our support team so they can reproduce the problem and debug what the failure is. It shouldn't take them very long to do so.
Or, you can try and do so yourself. Build a debug version of the kernel, then set a break point at those calls. Start single stepping through them and figure out which function actually returns the error. Eventually, you should wind up in the function HalTranslateBusAddress() which I believe will succeed. That is where the Logic code is. So if you don't fail there, then you must be failing somewhere else in the kernel.
Unfortunately, I can't try and reproduce it right now, so I'm just commenting off the top of my head based on what I remember about the code. If you can't run the debugger, call support and they will help you out.
Sorry,
--mikee
|
|
|
|
| 20 Jan 2005 10:22 AM |
|
|
ok. yes, Isa and size of 16 fails. I will poke around and try to see which addresses work and which do not.
0x70000000 works
0x6F000000 does not
0x63000000
0x60000000 does not
0x5F000000 does not
The HalTranslateBusAddress seems to accept both Isa and Internal by the way. the LOCE code does not check for anything in particular.
I am failing to build a debug kernel that does not fail with Ram start overlaps rom binary. It looks like I am starting a series of questions about kernel debugging....
|
|
|
|
mikee@logicpd.comNew Member Posts:
| 20 Jan 2005 11:09 AM |
|
|
The RAM overlaps ROM error just means that the image is too big. This happens because debug images tend to be 2-3 times the size of a retail image. Trim it way down by removing any unecessary components. The biggest culprits tend to be video, multimedia, and networking tools (IE, etc).
Start with just a simple headless device and add your driver into it.
--mikee
|
|
|
|
| 20 Jan 2005 01:22 PM |
|
Ok I build a debug kernel matching the quickStart guide (thanks for that).
I stepped through the code.
this fails in ddk_map.c:
*MappedAddress = CreateStaticMapping(AlignedAddr >> 8, AlignedSize); the values look good then. they are the one I passed.
Unfortunately I do not have the source code for:
tkfuncs.cpp nor mdarm.c so I stepped into those in assembly and did not understand what failed.
Help please!
Thanks
Luc |
|
|
|
mikee@logicpd.comNew Member Posts:
| 20 Jan 2005 01:48 PM |
|
lucb,
That is strange. Those functions aren't anything that we here at Logic would have modified in any way.
Did you install the "shared source" with Platform Builder? Most likely tkfuncs.cpp and mdarm.c can be found in the shared source. They would be under
X:\WINCE420\PRIVATE\...
My guess is that mdarm.c would be under:
X:\WINCE420\PRIVATE\WINCEOS\COREOS\NK\KERNEL\ARM\...
I've no idea where tkfuncs.cpp might be. If it isn't in the shared source directory, try the public directory.
If you didn't install the shared source, just pop Platform Builder's install disc back into your CD drive. It should be selectable as an install option.
I would also try posting to the standard WINCE newsgroups. Maybe check google's archive at:
http://groups-beta.google.com/group/microsoft.public.windowsce.platbuilder?hl=en&lr=&ie=UTF-8
--mikee |
|
|
|
| 20 Jan 2005 11:44 PM |
|
|
Ok I will do this. At this point I do not expect those functions to fail, but some value to not have been set properly by the Hal.
Like how does Win CE know the difference between mem space and IO space? maybe there is a gap there in the definition.
you might want to build a print hello application yourself and see if you can transbus a location in the 0x60000000 space
Thanks,
Luc
|
|
|
|
| 21 Jan 2005 02:48 AM |
|
update:
I was able to step through the CreateStaticMapping.
It goes immediately to mdarm.c and scans the OEMAddressTable to find the mapping between physical memory and virtual memory. That table has the following entries:
g_pOEMAddressTable[0] dwVA 0x80000000 dwPA 0xc0000000 dwSize 0x00000040
g_pOEMAddressTable[1] dwVA 0x84000000 dwPA 0xc4000000 dwSize 0x00000040
g_pOEMAddressTable[2] dwVA 0xb1000000 dwPA 0x00000000 dwSize 0x00000020
g_pOEMAddressTable[3] dwVA 0xb0000000 dwPA 0x80000000 dwSize 0x00000001
g_pOEMAddressTable[4] dwVA 0xbfe00000 dwPA 0x70000000 dwSize 0x00000001
g_pOEMAddressTable[5] dwVA 0xbfd00000 dwPA 0x70c00000 dwSize 0x00000001
g_pOEMAddressTable[6] dwVA 0xb1000000 dwPA 0x71600000 dwSize 0x00000001
g_pOEMAddressTable[7] dwVA 0xbfb00000 dwPA 0x70800000 dwSize 0x00000001
g_pOEMAddressTable[8] dwVA 0xbfa00000 dwPA 0x70600000 dwSize 0x00000001
g_pOEMAddressTable[9] dwVA 0xbf900000 dwPA 0x70200000 dwSize 0x00000001
g_pOEMAddressTable[10] dwVA 0xbf800000 dwPA 0x70e00000 dwSize 0x00000001
g_pOEMAddressTable[11] dwVA 0xbf700000 dwPA 0x71200000 dwSize 0x00000001
g_pOEMAddressTable[12] dwVA 0xbf600000 dwPA 0x71400000 dwSize 0x00000001
g_pOEMAddressTable[13] dwVA 0xbf500000 dwPA 0xb0000000 dwSize 0x00000001
g_pOEMAddressTable[14] dwVA 0x00000000 dwPA 0x00000000 dwSize 0x00000000
This shows that the slowCS area I am trying to use is not mapped in the system. Which explains the failure. (the size parameter in the table is in MB by the way ).
I believe I need to change the C:\WINCE500\PLATFORM\LoCE\src\inc\card_engine\lha400_10_config_bib.h to add the proper space. I would appreciate some help on this because I do not understand that linker language yet.
I suspect that if I add 1MB from 0x63000000 I will be ok with the TransBus Call.
Thanks,
Luc |
|
|
|