Missing peripherals when debugging F312

Where you starting a new project? If so, check the debugging section under "target options" and make sure you are not using "simulator" (default I believe on left side) and are using debugger with proper silabe DLL. Check one of your previous projects settings under debugging for comparison.
Good Luck
Andy

I am using the Silicon Laboratories C8051Fxxx selection on the right side, not the Simulator. I have Load Application at Startup and Go till Main() checked just like on the other projects. I can verify the program is being downloaded to flash as well, I just can't display the darned peripherals.

As far as the .dll, I know we have the latest version of the Keil IDE, C51 v7 installed. I would assume the installation contains the most up to date DLL as well since we've not experienced this problem with far newer cores. Would anyone happen to have a F312 processor they could check and see if peripherals are indeed supported on? I know this CPU doesn't use PAGING like the other ones we use do, so perhaps that has something to do with it. Thanks again for the help.

OK, sounds like you have the setup right. No experience with the 312 series myself.
Andy

I know this CPU doesn't use PAGING like the other ones we use do, so perhaps that has something to do with it.
No, but the f3xx is not a derivative, it is a deviate.


Erik

"the options for viewing the peripherals are missing when debugging through the JTAG connector."

I though they were only for the Simulator?

I though they were only for the Simulator?
I thought he ment the SFR list, if he is speaking of simulator peripherals when using the JTAG he is way off.

Erik

"Unfortunately this design was started by someone else, and I can't be entirely sure they didn't "break" it somehow"

You could check that by creating your own simple project from scratch...

No experience with the 312 series myself.

congratulations, they will drive you nuts. The SILabs f3xx are not derivatives, they are deviates.

Of course, you can always read the 350 page datasheet and carefully observe all the "cute little differences". Then when you use another chip you will need to make absolutely sure you forget them

a couple of examples with f3xx from before I threw the darn thing away and used another chip:
I use an external oscillator and for this stupid thing the clock input is XTAL2 ! so I burned a chip having connected the clock to XTAL1 as any sensible person would do.
Doing a search on RCAP2 it was not there. I coded by other "clumsy" means and later found that the RCAP2 is there with a different name. Why it had to be reanmed for any reason other than to make it absolutotally impossible for anyone that has been trapped to use another chip I can not figure out.

If you have any intention of using other derivatives avoid the SILabs F3xx You will be utterly confused.

Erik

PS: if you do not ever want to use anything else, and have no '51 experience, I am sure the the f3xx series are fine chips.

I Believe the OP is interested in using the dubugger in dubug mode with IDE and viewing the state of the peripherals (after program halt)with user defined break points via JTAG programmer and not able to make this happen (the peripherals dialog boxes are not available). My one and only chip experience was with the C8051F040 and the full peripheral options where available to me (in debug mode). I don't think this has anything to do with the simulator (never actually used it myself).

Andy

"I don't think this has anything to do with the simulator"

I thought that the only purpose of those dialogues was for use in the simulator - when you're doing "real" debug in a real target (eg, via JTAG) you have the real peripherals to work with, so you don't need the dialogues.

But I could be wrong - maybe that's just the way I used it; or maybe that is the way it was in UV2, but UV3 is different, or...

I would assume the installation contains the most up to date DLL
Wrong! The SiLabs driver is furnished by SiLabs - not Keil. Look in C51/Bin for Si8051.dll and check the version. Go to the Silabs web site for the latest driver.
Each time Keil or SiLabs makes a version change there seems to be a blivet for a short time.
I can never be sure which overwrites which dll so on a Keil version change, I uninstall SiLabs and Delete the driver entry in tools.ini.
I then re-install the latest SiLabs driver.
Seems like a lot of work but so is debugging code when it's a driver problem. I can make enough of my own problems.
Have not used the F312 but I use the F330 and the F005 and both have peripheral dialogs while running on the target eval boards.

Juason G: "I would assume the installation contains the most up to date DLL"

Al Bradford: "Wrong! The SiLabs driver is furnished by SiLabs - not Keil."

Al is correct - these "driver" DLLs are 3rd-party, so you always need to check at the source (SiLabs, in this case).

"I can never be sure which overwrites which dll so on a Keil version change"

It was the same with Triscend in the early days!
My solution was to rename the DLL file so that the version was explicitly obvious from the filename; eg,
Si8051-001.dll - 1st version
Si8051-002.dll - 2nd version
etc

and then add (not replace) entries in the Keil TOOLS.INI; eg,

TDRV0=BINMON51.DLL ("Keil Monitor-51 Driver")
TDRV1=BINISD51.DLL ("Keil ISD51 In-System Debugger")
TDRV2=Si8051-001.dll ("SiLabs v001")
TDRV3=Si8051-002.dll ("SiLabs v002")

My understanding is as follows:

The debugger contains both a simulator to debug with, as well as debugging via the JTAG connector to a working prototype. Currently I have a working prototype and when I want to test code I use the JTAG to download my code to the chip and test using breakpoints and halt commands as I step through my code.

With the F132 and F045 chip-board prototypes I have been able to step through and observe the peripherals (SFRs) during halt states. This includes the UART registers, Clock Registers, and MAC registers amongst other things. I believe each series of CPU has an entirely different makeup of SFRs and peripherals and that is fine, I mean the specific chip was chosen for a reason. It just so happens that the current project uses 5 boards total, all using a different series of SiLabs processor - VERY confusing at times :P

As a solution to the problem we replaced the F312 with the F310. The chips themselves are identical except for the F310 has 8k more flash on it. (The change was so we had more flash too, not just because of the debugger problems. And the pin-outs were identical thankfully!). I found that by selecting F310 in the debugger the peripheral (SFR) states could be seen on the F312, and everything worked fine. So yeah, it must be that specific deviate processor just wasn't supported in the DLL. I'll try updating when I get in to work and see if it helps. Is there any disadvantage to selecting F310 when I'm really using an F312? I don't want to run into some oddball problem later hehe.

As for the dialogues, I find them helpful to ensure the target is correctly configured. For example, I can step through my HardwareInit() function and watch the SFRs to ensure things like CLOCK speed, UART function and TIMERS are setup correctly. Many times if I misconfigure something the board crashes. If I halt before the crash I can see if perhaps I mis-set an SFR and debug from that angle. In this case I am adapting code from another 312 project, and it would have been helpful to see what that project's SFR states were post-configuration instead of manually parsing the initialization file to see what was done.

Thanks again for the help. We have found a workaround, I'm just not sure why the F312 series wouldn't let me view them, but the nearly identical F310 will. Probably the DLL.

observe the peripherals (SFRs)

Jason, please do not invent new names for things. If you look through this thread, you will see how much confusion your "renaming" of the SDFRs have caused.

You may have come form a world outside the '51 where something similar is called "peripherals", however, I have never before heard a '51 SFR called a "peripheral".

Erik

Jason,
Sounds like problem solved. This is a good resource for silabs related problems.
http://www.cygnal.org/ (if you havn't already)
You may even get an explanation of the problem. If you do decide to persue further on there site, I would recomend pasting the link to this thread for reference. Good luck, sounds like you'll need it with this one.

Andy