Skip to main content
frankmeyer9
frankmeyer9
Associate III
March 14, 2012
Question

Atollic Toolchain Bug ?

  • March 14, 2012
  • 4 replies
  • 993 views
Posted on March 14, 2012 at 16:22

I had a strange problem with the Atollic TruStudio Lite toolchain, V2.2.

In my project, I had the USART receiving data in the interrupt handler into a buffer, and a main thread evaluating this data, called from main.

First, I had defined that buffer as:

char  buffer[BUFSIZE] = {0};

in main.c, and declared it as:

extern char  *buffer;

in stm32f4xx_it.c.

Building the project this way, I received all bytes correctly, but the buffer contained nothing but zeros.

If I defined the buffer in the module containing the interrupt routine (stm32f4xx_it.c) and declared it in main.c, the buffer was filled correctly, but landed in the HardFaultHandler when trying to access this buffer.

The problem went away when I declared that buffer as:

extern char  buffer[BUFSIZE];

in stm32f4xx_it.c.

Did I miss something ?

For all the time I remember, it was legal to declare a pointer to an external variable, and use array subscription. With other words, a pointer and an array name were treated equally.

This was not a C++ project, as Atollic Lite does not support C++.

#atollic-lite-stm32f4discovery
This topic has been closed for replies.

4 replies

Tesla DeLorean
Tesla DeLorean
Guru
March 14, 2012
Posted on March 14, 2012 at 20:49

Sounds like it's not achieving the appropriate linkage. But technically the original assignment is not a pointer, but rather an address, and can't be reassigned. Try doing buffer = NULL; and see what kind of errors that throws in the primary source.

You should be able to create a suitable exemplar, and provide it to Atollic through their forum or tech support.

Their 3.0 evaluation release is substantially less restricted and broken.

Tips, Buy me a coffee, or three.. PayPal Venmo (See Profile) Up vote any posts that you find helpful, it shows what's working..
frankmeyer9
frankmeyer9Author
Associate III
March 15, 2012
Posted on March 15, 2012 at 12:05

The linkage was one thing I checked. At least, both pointed to the same RAM address. I did not want to verify it down to instruction level, because the basically same method worked in other projects.

I understood that ''char *array'' and ''char array[N]'' is not the same in C++, but I recall it was in plain C. And I recall vaguely, it still worked as expected under V2.1 with a VL_discovery board.

> You should be able to create a suitable exemplar, and provide it to Atollic through their forum or tech support.

Do they have a forum ?

I did not find one where to post my issue, albeit not searching for more than 3 or 4 minutes.

I have heard about the turn in Atollics crippling strategy. I hesitate to update, for several reasons. The 32k limitation is a constraint for some of projects. But basically, it came too late for me. The former versions only supported STM32 parts. This meant another GUI for each family, partially forcing me to use Windows (not my preferred OS). Now that I ordered a Crossworks licence, Atollic announces this...

Bad timing, at least for me.

And finally: Eclipse might have it's fans, but I don't count myself into this category. I can work with it, but still wonder about strange workflows and copiously distributed settings.

But this is just personal taste.

Tesla DeLorean
Tesla DeLorean
Guru
March 15, 2012
Posted on March 15, 2012 at 18:09

char  buffer[BUFSIZE];

Is not a pointer, ie an address whose content point to another address where the data actually resides.

It is an absolute address, containing character data.

// Source A

char  buffer[BUFSIZE] = { 0 };

// Source B

extern char *buffer; // The value of buffer as a pointer, would presumably be ZERO at initialization time

printf(''buffer is %p\n'', buffer);

And for the same reason you can't do this

char  buffer[BUFSIZE] = { 0 };

// ..

buffer = ''Something else''; // ''declaration is incompatible with ''char buffer[BUFSIZE]''

Neither of these are bugs. So it would be somewhat fool hardy to report it as such.

That said, I'd agree that the original Atollic Lite seemed to be an ''Own/Home Goal'' when it comes to what an evaluation needs to achieve in the commercial sense.

Tips, Buy me a coffee, or three.. PayPal Venmo (See Profile) Up vote any posts that you find helpful, it shows what's working..
frankmeyer9
frankmeyer9Author
Associate III
March 16, 2012
Posted on March 16, 2012 at 07:55

You are correct about this: ''char buffer[SIZE];'' is not a pointer.

But ''buffer'' is, pointing to the first element in the array. When defining ''char *buffer[SIZE] = {0};'' in one module, I expect the compiler to reserve (SIZE * sizeof(char)) bytes for that buffer. The initialization enforces a definition.

When I declare ''extern char *buffer;'' in another module, I expect to get a pointer to a char-sized variable, and according to the linkage rules, this pointer should refer to the buffer defined in the first module.

There is no size information in the second module, it is just a pointer to (one) char. C allows me to use array subscription even in the second module, or increment the pointer - on my own risk.

At least I thought so. As I said, I used this method in different occasions, and it worked. I don't know why the Atollic compiler/linker is not capable of correctly linking the second variable (declaration) to the first one (definition) without the size information.

I vaguely remember that in C++, this is slightly different. Having:

char  buf1[SIZE1];     and

char  buf2[SIZE2];

''buf1'' and ''buf2'' are not of the same type if SIZE1 is different from SIZ2.

But I haven't done a lot in C++, and nothing in the last years.

The C90 and C99 standard seemed to me like steps in the C++ direction - maybe I missed something here. At least with gcc, I explicitely have to define -std=c99 to get those features.

Terms & ConditionsAccessibility statement