We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Hi all,
I have a problem.
I can simulate my application (C and Keil uVision5). Target: LPC824 But, simulator stopped at one line: wait for PLL Locked.
After change PLL control register (SYSPLLCTRL), application must wait while bit LOCK in SYSPLLSTAT register is zero. In realtime debugging in target working fine, but in simulator don't work - SYSPLLSTAT don't changed.
Please, How to simulate changes in SYSPLLSTAT register (this is read-only register)?
LPC82x User's manual: www.nxp.com/.../UM10800.pdf - see 5.6.4 on page 35
Thank you.
peter
I had the same issue with the LPC812 and just decided to have a special build with that loop commented out.
Hmm,
I cannot change source code due to simulation... :-)
Ok, after very quick study I found solution.
- Create file simulation.ini with this content:
FUNC void Setup (void) { _WDWORD(0x4004800C, 0x00000000); // PLL not Locked - default value SP = _RDWORD(0x00000000); PC = _RDWORD(0x00000004); } LOAD %L INCREMENTAL // Download Map 0x4004800C , 0x4004800f READ WRITE; // map this location (reg SYSPLLSTAT) as R/W define button "Toggle PLL Lock bit", "_WDWORD(0x4004800C, 0x00000001 & (!_RDWORD(0x4004800C)))" ; // click will toglle value of SYSPLLSTAT Setup(); // Setup for Running g, main
- select this file in dialog "Options for Target '...'" -> Debug Tab -> initialization file for simulator - now start debug (Simulation) - Go MENU->VIEW->TOOLBOX WINDOWS, and now You can see toolbox with new button. Try to press it...
This is only quick solution for today (maybe not ideal, but sufficient for me).... :-)
You need to do work-arounds if trying to simulate a processor where some processor hardware isn't simulated. For a virtual processor, you don't need to worry about any PLL getting a lock, so it's ok to ignore the test.
There are other hardware modules that are way harder to work around in the test software. When you need eth, USB etc, then there are no reasonable workarounds.
These registers aren't in the "ARM Core", they are vendor circuity peripheral to the core.
Some people use and have access to gate level simulation, they also have very big checkbooks.
You try to make your software sufficiently abstracted that you can test it's core functionality in a test harness, and emulate the hardware with your own software at the edges.