Debugging WinCE BSP with XDS100 & CCS5.2

Hello,

Yes, it helped me forward a bit. From the document you provided, I understood that there is no way to debug the WinCE bootloader, at least with XDS100. Which is a shame. One option is ofcourse to use Linux bootloaders that will load the CE kernel, but for some unknown reason it feels kind of unnatural for me.

The whole problem started from the fact that the CE bootloader does not even reach the phase, where serial initialization takes place, therefore serial debug is out of question. I hoped to debug the bootloader with JTAG and hoped that XDS100 would do the trick. I was mistaken. My bad. Lesson learnt.

Thank you very much for prompt answer.

Hi,

I am not sure which document you are referring, but the u-boot debug procedure shows how to catch the processor at the very early stages of the system initialization and the video even shows how to halt the processor after a reset, which seems what you want to do. It obviously describes the procedure using the features, project source code and the binaries from u-boot, which we know for sure allows a complete source-code debugging.

In this case, the same concepts and CCS options are applicable to the BSP code and you should have a similar capability of halting and single-stepping the core at the very early stages of the boot. All in all, the XDS emulator can obtain complete low-level control over the target core. The big question mark is if source-code debugging will be available, as it is dependent on the type of binary and debug symbols generated by the tools used to build the BSP.

The Linux debug procedure is at a later stage in the initialization (when u-boot is already long gone) and therefore seems a lot more high-level for you.

Hope this helps,

Rafael

Hello,

I guess i expressed myself a bit wrong way :)

It feels a bit wrong for me to have the bootloaders (xloader & u-boot) taken from the Linux BSP (compiled with GNU toolchain) and then kernel image itself from the WinCE BSP (compiled with MS toolchain). Also having the binaries in different format (ELF for bootloaders vs kernel in COFF).

But I guess that's the life is currently and nothing we can do about it.

What comes to ELF format bootloaders, these i managed to debug properly while ago, set breakpoints, run-to and all other fancy features and CCS works the most excellent manner there. Also modifying hardware registries etc. Everything works like a charm. Now if it would support COFF (or any other MS binary format) for debugging, it would be the perfect tool. :)

But, I keep searching. There has to be a way to use JTAG with binaries created with MS toolchains :)

Hi,

Thanks for the clarification; I think you are very well aware of the initial debug procedure.

Regarding u-boot loading WinCE, I know it feels strange but, all in all, u-boot simply loads raw binary code to the memory (it could be Linux or WinCE, as binaries are bit streams) and points to its initial address. It obviously performs some hardware initialization (DDR, RS232, Ethernet, etc.) but that would be necessary in any case. In the case of Linux, it also passes parameters to its kernel (as if it was calling a function), which I don't know if WinCE kernel would accept them.

Also, CCS supports COFF but it is in a format used by our code generation tools (the TI compiler set). In this case you could try to load a Microsoft COFF binary and see if the debugger is able to interpret it correctly. Not sure, I never tried. 

You got me curious - I can't promise anything, but I would love to try it someday. Maybe some other developer was able to use this combination and could give some tips.  

Regards,

Rafael

Hello,

well, in principle you are correct. It does not make absolutely no difference, where i load the kernel from. But when i take it from the commercial point of view, mixing toochains within one project scope (gcc toolchain for bootloaders and MS toolchain for CE kernel) most definitely turns into a nightmare. And explaining it to customer would be even bigger nightmare. I'd like to keep things simple and straightforward: one project, one toolchain (wherever possible).

So, whenever someone figures out, how to debug bootloaders compiled with MS toolchains using XDS100 and having Pandaboard as target board, i would be very glad to know about it.

And if i figure out something, i will definitely post it here.