Hello,
I'm using a Keil LPC1868. The running program on the target is able to receive debug messages via the JTAG interface. On the target side, the ITM_RxBuffer is used to read the messages. Our debug software uses the UVSOCK interface to send data to the target via Keil. Therefore, we use the library function UVSC_DBG_SERIAL_PUT(int iConnHandle, SERIO *pSerIO, int serIOLen) with pSerIO.nChannel=3 and pSerIO.itemMode=0.
This works fine when executing the program on the actual target device. But when using the Keil simulated hardware, the ITM_RxBuffer seems to receive only one byte, and in addition, the value of this byte is not correct.
The documentation for UVSOCK says, that Channel 3 uses the Real-Time Agent Terminal and "If the Real-Time Agent is present in the target, this operation is possible for the Real-Time Agent terminal in both Simulator and Target modes."
Does anyone have an idea how to solve this issue or where I should have a look at?
I'm very grateful for every hint or suggestion.
Best regards, Joachim Engelhardt
In the meanwhile, I contacted the support of Keil and got the answer: The simulator actually works not correct for this case. The solution is, to send the information byte by byte, so each API call sends only one byte. Because there seems to be too less interest in the simulator, they spend very less effort in the future development of the simulator, so they don't expect a correction of this behavior.
But I got the promise, that the developer notes for this section will be extended soon to address this issue.
I originally selected the Keil tools because of the simulator. Alas, they don't seem to like to add much simulation support for newer processors - even processors that are almost bit-by-bit identical with supported processors.
We likewise selected Keil for ARM due in large part to the simulation capabilities. It was the major time that set Keil ahead of competing tools.
If you look at their older tools, they hype the simulator up as the best way to test / debug embedded designs due to the difficulty / complexities of debugging on chip.
Having spent hours looking though the 3" thick technical reference manuals of various uC's for specifics on the more intricate peripherals (CAN or advanced timers) and finding conflicting information, I can surely appreciate the difficulty in fully and accurately simulating parts.
They indicated a few years ago an unfortunate deliberate decision to migrate resources to better in circuit debug tools due to the difficulties simulating peripherals. Now you can buy the $1k debug probe.
I did have a recent problem with wwatch(a vtreg such as can0Out) in mdk5.17 where it only sent 1 printf command result to the command window. They finally acknowledged it and fixed it (new uv4.exe). Support indicated there was some change in the simulation just prior to mdk 5.15 to more accurately time things. It seems they are continuing simulating but not as complete.
Reduced simulation support seems to encourage a CPU independent HAL in the simulator and possibly to bypass hardware and communicate with embedded program's HAL if simulation is of significant benefit.