Accessing IO/peripheral registers in codeblocks

Go To Last Post
16 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

As i finally has flipped the switch, converting 100% to linux, I must admitt that life has been easier. For many years I have had reduced focus on Atmel and AVR8'd due to my reluctant relationship with atmelstudio, but now I will start to use these chips more frequently. I want to use codeblocks or codelite as my preffered IDE's (for the moment) and I have, to my surprise, quite easily setup the environment to use codeblocks with avrgdb using avrdude and avarice as programmer and gdb server. This works everytime and it is also way more responsive than studio ever was.

cool

 

However, I have a few problems.

 

1) Most important, for the moment I do not have the ability to access IO/peripheral registers, only CPU registers. When I deal with STM32F4 devices (cortex) I use SVD files. I guess there must be an AVR counterpart somewhere?

 

2) GDB seems to have issues with setting and clearing breakpoints. I have to manually enter the gdb command if I want to ensure that all breakpoints are cleared. Also, when setting a breakpoint before debbugging, they sometimes do not get set when starting to debug. I will investigate this further and start logging the GDB communication, butif there is any known issues with codeblocks and avrgdb + avarice please inform.

 

Thanks

 

So thats it for to night, No I will go watching "The Martian"... Looking forward to it

Regards
Vidar (Z)

----------------------------------------------------------

"The fool wonders, the wise man asks"

Last Edited: Sun. Mar 27, 2016 - 10:26 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

1) avr-gcc programs start

 

#include <avr/io.h>

 

that defines all the SFRs. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

... umm, for the debugger also? I'm talking about debug windows like wathces, CPU registers and memory-dumps, and in this case a window that could show status of, and allow editing, of all the peripheral registers, or SFRs if you like, while running the debugger. I guess I was not clear on that.

 

 

 

 

Regards
Vidar (Z)

----------------------------------------------------------

"The fool wonders, the wise man asks"

Last Edited: Mon. Mar 28, 2016 - 09:57 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Oh no, because they are #defines, not global variables, those symbols don't make it as far as the -g information in the ELF/DWARF2. You could, of course, do that by ditching io.h and defining them in that way. In fact you could probably write a script in something like Python to take the existing ioXXX.h and generate a new copy in terms of C vars. 

 

Studio achieves named registers in the debugger by using XML part description files and mapping names to locations. If one wrote a wrapper for gdb it might be possible to implement a similar approach. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I guess these xml files is the AVRs, or Atmels, counterpart to  ARMs SVD files as used by the IDE (emblocks, which is based on codeblocks) to gain peripheral register information whilst debugging. Em:blocks has the option to add a SVD file when setting up the debugger for a certain project and the SVD file is specific for the cpu/mcu used in that project, giving the missing information. SVD files are written in XML and defines all registers found in the cpu/mcu

 

Since emblocks is based on codeblocks one could hoped for such options for codeblock aswell but the latter was not written for embedded debugging afaik. However, that was the purpose of making emblocks, which branched off codeblocks, and for which they added the needed features like the one above. But, they broke the cross-platform support in the process since they used some shortcuts in coding using tools that was bound to a certain os. Thats a pitty since emblocks (now changing name to embitz) was really great (or is for the windows environment when debugging Cortex processors).

 

Maybe it Is possible to add new menus/features to codeblocks using phyton? I was thinking that the "debug window" menu under "debug" needs an extra option like "Peripherals". This could be the frontend of a new feature that could interpret the very same "XML part description files" that studio use. ... Talking about studio. I tried to search for xml files in the studio installation folder but found nothing. Guess they have a different extension. Could have been .pdf for PartDescriptionFile, but, well, that extension is kinda taken already. Do u know what these files are named and where ti find them? I would like to take a look at them to grasp an idea of how to get this as a feature for codeblocks.

 

 

 

Thanks

 

 

 

 

Regards
Vidar (Z)

----------------------------------------------------------

"The fool wonders, the wise man asks"

Last Edited: Mon. Mar 28, 2016 - 01:56 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just install AS6/AS7 on a Windows machine then search for *.xml within the installation. They'll be obvious because there's something like 300 of the things. If code::blocks can already read these SVD/XML files then it shouldn't be beyond the wit of man to modify it to use the Atmel format perhaps.

I don't know if such things in C::B have to be in C but if it's possible to use Python then I recommend the ElementTree lib for a simple way to read XML.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

In 6 they are *.xml, in 7 they are *.atdf (same format, just new extension).

 

The atdf files are shipped as part of the packs, so you can unzip any of the public packs to access the atdf files.

 

SVD is a "proprietary" (and somewhat crazy) Keil/ARM xml format, so Atmel Studio uses atdf for all architectures. The packs for SAM devices contains svd files as well where we have them.

:: Morten

 

(yes, I work for Atmel, yes, I do this in my spare time, now stop sending PMs)

Last Edited: Mon. Mar 28, 2016 - 04:49 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm tempted to have a crack at a Python tool to read ioXXX.h and convert #defines into global C symbols that would carry through to the -g and map etc. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
If code::blocks can already read these SVD/XML files then it shouldn't be beyond the wit of man to modify it to use the Atmel format perhaps.

Code::blocks can't, but em::blocks, which is branched out from code::blocks, do. But as mentioned, em::blocks favored micro$oft and had its cross-platform support broken.

 

*.atdf.... good, found it. It looks at first glance a bit similar to SVDs, bu then again all XMLs looks similar to me. I had a thought. Since em::blocks is based on code::blocks it might be so that the part rewritten for adding SVD support ain't to impossible to merge back into a code::blocks build. It might not be this part of em::blocks code that has broken the cross-platform support. Then to also add support for atmel atdf files might not be that difficult. I will ask em::blocks developers to share some light and invite them for some discussion.

 

 

 

 

 

Regards
Vidar (Z)

----------------------------------------------------------

"The fool wonders, the wise man asks"

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
I'm tempted to have a crack at a Python tool to read ioXXX.h and convert #defines into global C symbols that would carry through to the -g and map etc.

 

FYI.:

 

Seems that someone has been working on this lately,

https://spaces.atmel.com/gf/proj...

 

 

EDIT:

 

Never mind.... ITS YOU!  blush

 

 

Regards
Vidar (Z)

----------------------------------------------------------

"The fool wonders, the wise man asks"

Last Edited: Wed. Jul 27, 2016 - 11:44 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Indeed it is. If you use that let me know how you get on, any problems etc.?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Will try it, be sure, but noticed that under "Trove Categorization" and "Microprocessor", you listed AVR Mega and AVR Tiny only. Any problems with xmegas?

The atdf files for both megas and xmegas are using the same format afaik.

 

 

Regards
Vidar (Z)

----------------------------------------------------------

"The fool wonders, the wise man asks"

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Only reason is that I have never tried it with xmega .adtf files (or even Tiny for that matter) but I guess it should work as I expect the XML to follow a similar format (never looked). I was going to say that Atmel already beat me to the punch in that they already define Xmega as structs anyway (in fact it's kind of the reason I wanted the same for tiny/mega) but I guess there scheme all falls down because they don't combine all the structs into one big struct that defines the entire chip layout (as a C symbol) so the gdb debugger won't see that DACB is based at 0x420 or whatever it is. That's the reason I have the very top level "USE_SFRS()" because it instantiates a struct pointer (pSFR) that points to a layout of the entire chip and is assigned one base address that is START_SFRS (0x20 on most chips).

 

When I'm next near a computer that has Studio 7 (and hence .adtf files) I must take a look at some Xmega ones and see if my avrrread thing can parse them.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The only thing I see (that is obvious at least) with your parser is that you go straight into /avr-tools-device-file/modules. This works on tiny and mega, but once you enter xmega you'll see (xmega32e5, VPORT for instance), that a module can be instantiated multiple times with different offsets (and in different address-spaces, theoretically). So you should look at /avr-tools-device-file/devices/device/peripherals/module/instance to get the instance data, and then use the /avr-tools-device-file/modules/module to create the module instance.

 

Re the USE_SFRS, that's not a bad idea... would mean that the symbol info is not discarded from the elf so that it can be evaluated... I like it :) 

:: Morten

 

(yes, I work for Atmel, yes, I do this in my spare time, now stop sending PMs)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

But that only works because the equivalent of:

#define VPORT0    (*(VPORT_t *) 0x0010)  /* Virtual Port 0 */
#define VPORT1    (*(VPORT_t *) 0x0014)  /* Virtual Port 1 */
#define VPORT2    (*(VPORT_t *) 0x0018)  /* Virtual Port 2 */
#define VPORT3    (*(VPORT_t *) 0x001C)  /* Virtual Port 3 */
#define OCD    (*(OCD_t *) 0x002E)  /* On-Chip Debug System */
#define CLK    (*(CLK_t *) 0x0040)  /* Clock System */
#define SLEEP    (*(SLEEP_t *) 0x0048)  /* Sleep Controller */
#define OSC    (*(OSC_t *) 0x0050)  /* Oscillator Control */
#define DFLLRC32M    (*(DFLL_t *) 0x0060)  /* DFLL for 32MHz RC Oscillator */
#define DFLLRC2M    (*(DFLL_t *) 0x0068)  /* DFLL for 2MHz RC Oscillator */
etc.

is

typedef struct {
    VPORT_t  VPORT0;  /* Virtual Port 0 */
    VPORT_t  VPORT1;  /* Virtual Port 1 */
    VPORT_t  VPORT2;  /* Virtual Port 2 */
    VPORT_t  VPORT3;  /* Virtual Port 3 */
    OCD_t    OCD;  /* On-Chip Debug System */
    CLK_t    CLK;  /* Clock System */
    SLEEP_t  SLEEP;  /* Sleep Controller */
    OSC_t    OSC;  /* Oscillator Control */
    DFLL_t   DFLLRC32M;  /* DFLL for 32MHz RC Oscillator */
    DFLL_t   DFLLRC2M;  /* DFLL for 2MHz RC Oscillator */
    etc.
} entire_chip_def;

#define USE_SFRS() volatile entire_chip_def * const pSFR = (entire_chip_def *)0x00nn

Which gives a base symbol called pSFR that the user can use in the debugger to watch pSFR->whatever

 

You'd need something like this for the "complete solution". Also in the above I just assumed all the function blocks are adjacent. If there are gaps you'd need to pad out with "resereved[N]" in various places above. That, essentially, is what my Python tool is constructing for tiny/mega.

 

I think you're right, this is not going to work for Xmega - though I need to take a look at a .adtf and see how little work it would be to add it. (then again I've never seen any point in the Xmega itself, at all - once you get there you might as well be using an M0(+) anyway ;-)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It's the same concept for xmega and up (including uc3 and Cortexes).

 

You would end up with something similar to our xmega structs then, with reserved_nn to pad out the struct with gaps (basically, the xmega and the SAM ways of using structs are quite similar)...

:: Morten

 

(yes, I work for Atmel, yes, I do this in my spare time, now stop sending PMs)