About friendly kitl debugging

The BSP provided by friendlyarm does not support (or is not correctly supported) kitl, so it is impossible to implement the driver without a hardware debugger.

Source code-level debugging. For convenience, we decided to make this BSP support kitl.

First, let's talk about two methods to obtain debugging information without a hardware Debugger: debug port and kitl.
Debug port
In most cases, the debug port is actually a serial port. We can let our driver print some information from the serial port, such
"Depends on how the program ran to this ghost place ." Earlier ce systems also supported parallel output of debugging information, but they are no longer needed.
This method is simple and can be used for both Bootloader and kernel. The disadvantage is that it is too simple to perform interactive debugging.
The function that outputs information is dbgoutputstring (...) in the boot stage. You can also use edbgoutputdebugstring
Let's talk about kitl.
Kitl requires ce Kernel support and interacts with developers through a hardware interface. You can break a breakpoint and observe the variables,
Basically, it is a complete source code-level debugging environment. The disadvantage is that it cannot be used for Bootloader and can be used only after the kernel is run.
Currently, Ce supports three interfaces: serial, Ethernet, and USB.

Now let's go back to the BSP provided by friendlyarm. This BSP uses an odd way to define debug port and kitl,
See options. h:
# Define kitl_xxxx xxxx
Use this macro for both debug port and kitl. In other words, this BSP sets the debug port and kitl as the same hardware interface,

This is not a fight. So we delete all the rows about kitl_xxx in options. H (in tiny6410,

Keep and open # define kitl_serial_uart0), and write the settings in platform \ smdk64 \ smdk6410.bat:

------------------------------------------------------------------------------
Rem disable all serial drivers
Set bsp_noserial = 1
Set bsp_nouart0 = 1
Set bsp_nouart1 = 1
Set bsp_nouart2 = 1
Set bsp_nouart3 = 1
Set bsp_noirda2 = 1
Set bsp_noirda3 = 1
Rem Disable debug port
Set bsp_debugport =
Rem kitl uses uart0
Set bsp_kitl = serial_uart0
-------------------------------------------------------------------------------

The above settings allow kitl to use serial port 0 and disable the debug port function. Why do we need to disable the debug port? Because I

There are no two serial ports, and I am not sure about the USB kitl for the moment, so I have to do this first.

Why is it written in the BAT file? I cannot tell you this. Many official BSP companies do this, including but not limited:
PXA255, pxa310, smdk2410
Then, in the sources file, set the C compiler macro based on the environment variables set by BAT:
Platform \ smdk6410 \ SRC \ kitl \ sources:
Add:
---------------------------------------------------------------------

! If "$ (bsp_kitl)" = "serial_uart0"
Cdefines = $(cdefines)-dkitl_serial_uart0
! Endif

! If "$ (bsp_kitl)" = "serial_uart1"
Cdefines = $(cdefines)-dkitl_serial_uart1
! Endif

! If "$ (bsp_kitl)" = "serial_uart2"
Cdefines = $(cdefines)-dkitl_serial_uart2
! Endif

! If "$ (bsp_kitl)" = "serial_uart3"
Cdefines = $(cdefines)-dkitl_serial_uart3
! Endif

! If "$ (bsp_kitl)" = "usbserial"
Cdefines = $ (cdefines)-dkitl_usbserial
! Endif

Platform \ smdk6410 \ SRC \ oal \ oallib \ sources
Add:
--------------------------------------------------------------------------------
! If "$ (bsp_debugport)" = "serial_uart0"
Cdefines = $ (cdefines)-ddebug_port = 0
! Endif

! If "$ (bsp_debugport)" = "serial_uart1"
Cdefines = $ (cdefines)-ddebug_port = 1
! Endif

! If "$ (bsp_debugport)" = "serial_uart2"
Cdefines = $ (cdefines)-ddebug_port = 2
! Endif

! If "$ (bsp_debugport)" = "serial_uart3"
Cdefines = $ (cdefines)-ddebug_port = 3
! Endif

This is almost the case. However, it is slow. kitl can be enabled or disabled in bootloader,
Unfortunately, superboot does not have this function.
So we force enable:
In kitl. C, modify:
-----------------------------------------------------------

Bool oemkitlstartup (void)
{
...
// Force startup kitl
If (0/* (pargs-> flags & oal_kitl_flags_enabled) = 0 */)
{
Retailmsg (1, (text ("kitl was disabled from eboot !! \ R \ nplease set kitl configuration in eboot !! \ R \ n ")));
Return false;

}

...

}

Okay, now clean sysgen, burn the program into flash. After starting it, you can see that the serial tool shows that kitl has been started.
Close the serial port tool and select connectivity options under the target menu of vs2005,
Select serial for transport, set the port, select kdstub for debugger, select none for download, and click debug-> attach
After a while ...... No, it was a conference. Something came out in the output window of vs2005 and told you to connect to the device.
Why is it a conference? We need to understand that the speed of the serial port is very slow ......
It took me five minutes to print the debugging information of nearly a thousand lines on my kitl, but the CE drifting interface still failed. MD, no more!

Conclusion: There is no problem with the kitl framework, but serial is too slow and not practical at all.
Next step: complete USB kitl.
Time: next year.

By the way, there is another point: the project was thin before the debug version was compiled. The tiny6410 Ram cannot fit the debug version of the original friendlyarm project.

Supplement 1: most of the above texts can be used freely. However, friendlyarm is prohibited from using the above text and modifying its own BSP Based on the above text.
Supplement 2: Supplement 1 is a joke. Ignore it. It is estimated that engineers at friendlyarm will laugh at the boy's arrogance and ignorance.