Problems running a program under Keil's simulator - Blinky.c for LPC812

lpcware · ‎06-15-2016

Content originally posted in LPCWare by jcdmelo on Sun Dec 23 18:51:47 MST 2012
Hi all,

I am trying to simulate the basic Blinky program under Keil's simulator (MDK 4.60, with the addon for LPC800), but I keep getting error messages like:

*** error 65: access violation at 0x40048080 : no 'read' permission

Any R/W access to other registers cause such errors, even data registers like LPC_GPIO_PORT->W0. This behavior makes configuring the device useless. I also noticed that no peripherals are available for viewing in the debugger.

Am I missing something, or is it too early to get an actual running environment for the LPC800 family? Hopefully, the code is being generated correctly. In fact, I'll have a board to check that out this coming week.

Thanks for any pointers,

Julio

lpcware · ‎06-15-2016

Content originally posted in LPCWare by robertkendrick on Sun Jan 19 09:31:38 MST 2014

Quote: MarcVonWindscooting

Quote: robertkendrick

I was responding to and trying to help someone else's problem.

Of course, you're right. I apologize for my impolite post.
That should not be they way to say 'hello' to a new member here who contributed a solution in his first post, really.
I hope we will do better, after this false start.

I'm not a strict opponent of simulation. I'm using ltspice in some cases. I avoid flashing the devices for development, where possible. It's a different approach, however, see: http://www.windscooting.com/softy/ramloader.html
That way, I can run (small) programs easily on the target core and peripherals without wearing down the FLASH :bigsmile:

No need. I can see how this developed from both sides. And yes, I can do better.

I was sceptical of simulation when I started working with these types of uCs. How could the peripherals been simulated to a real-world degree! Have used a few Eclipse based IDEs and they are very good. But for me they tend to lack any kind of simulator. Keil's IDE isn't perfect but its simulator is extremely good. IF your chip is fully simulated by Keil (and that's the issue) you can do amazing things with the simulator.
For example:
Simulate the USARTS right down to displaying a screen (with say a menu) AND typing in the choices on the same screen as if it was on your real hardware display device.
OR
Configure a timer, say to output a square of known frequency on a pin, and use the in-built Logic Analyser tool to see this square wave within the IDE and measure period, pulse width etc to confirm your timer calculations.
etc etc

Your ramloader is an interesting concept. Will take a detailed look. Have used to Keil to load programs into RAM and have executed them from there but I'm not sure if its as efficient.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by MarcVonWindscooting on Fri Jan 17 11:21:25 MST 2014

Quote: TheFallGuy

Why do you think you are going to wear down the flash?

It's not a real problem, it's a mental problem of people like me.
If I had a black box, that explodes with a probability of 1 in 100000 if I press the red button on it, then I wouldn't press the button! But I'm going to use my car to get home in a few minutes... :~
Irrational behaviour. I'm human.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by TheFallGuy on Thu Jan 16 14:07:08 MST 2014
Why do you think you are going to wear down the flash? It has something like 10,000 write cycles as a minimum and more like 100,000 typical. How many time do you expect to,be rewriting the flash on one part?

Regarding simulation. Why simulate when you have real hardware. Simulation will never replicate the real hardware. An lpc costs from $1.50-$8, so it can't be cost.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by MarcVonWindscooting on Thu Jan 16 13:51:03 MST 2014

Quote: robertkendrick

I was responding to and trying to help someone else's problem.

Of course, you're right. I apologize for my impolite post.
That should not be they way to say 'hello' to a new member here who contributed a solution in his first post, really.
I hope we will do better, after this false start.

I'm not a strict opponent of simulation. I'm using ltspice in some cases. I avoid flashing the devices for development, where possible. It's a different approach, however, see: http://www.windscooting.com/softy/ramloader.html
That way, I can run (small) programs easily on the target core and peripherals without wearing down the FLASH :bigsmile:

lpcware · ‎06-15-2016

Content originally posted in LPCWare by robertkendrick on Thu Jan 16 03:46:15 MST 2014
"Respect their interests. Respect their non-willingness to solve your problem #1 of the other today."

From my perspective respect was never in question here and it wasn't my problem. I was responding to and trying to help someone else's problem.

As to the question of 'simulation - What for?' well that's a whole new debate but if you like to spend your time coding, flashing, debugging and re-coding, re-flashing, debugging then that's up to you. A good simulator will a) make initial development a lot faster
b) improve the speed of the learning curve for a new device

lpcware · ‎06-15-2016

Content originally posted in LPCWare by MarcVonWindscooting on Wed Jan 15 15:31:06 MST 2014
The original poster posted once.
Never did anything else on the forum.
Asked a question, most people here don't care about - simulation of a uC? What for??

It happens to everyone. People don't care about my posts, too, and I can't blame them for it. Too off-topic (multithreading for example). You will get used to it.

There are not too many people here. This limits the time effort to reasonable values.
The perfect size of a forum consumes not more time as you would spend with your buddy talking about new projects/problems/cool solutions/... - if you had such a buddy. That buddy would occasionally tell you, he's doesn't like your idea. Or he woud tell you: "No, I have NO IDEA how to solve your problem". And you would understand he has a) no knowledge about your problem, and b) no interest in solving it on behalf of you.

I have never had a 'real world' friend who's interested in uCs in general or LPCs ins special. And this forum - with this size - is a premium selection of people of similar (never identical) interests you will never find across the street. Respect their interests. Respect their non-willingness to solve your problem #1 of the other today.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by robertkendrick on Wed Jan 15 12:11:30 MST 2014

Quote: TheFallGuy
This is a well supported forum for NXP products. Sounds like you were having problems with the Keil product and so should have asked they question on their forum...

Yes a Keil problem no doubt, but in nearly 21 months nobody bothered to reply to the original poster. And this is not an isolated instance of posts going unanswered.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by TheFallGuy on Wed Jan 15 10:18:41 MST 2014
This is a well supported forum for NXP products. Sounds like you were having problems with the Keil product and so should have asked they question on their forum...

lpcware · ‎06-15-2016

Content originally posted in LPCWare by robertkendrick on Wed Jan 15 10:05:17 MST 2014
What a poorly supported forum this is.

I would have thought the someone from NXP would be on to this quickly as it appears to be a problem with all their example programs running under Keil uVision.

For some reason the peripheral memory areas (0x40000000 ->) on NXP LPC processors don't seem to be mapped within the Keil IDE. This is why Keil is giving the error 65: Access violation message.

It can be fixed by using the Keil MAP command to map these areas:
Eg map 0x40000000, end address, read write

See Keil MAP command in IDE help