Author Topic: STM32 - IAR Workbench build errors  (Read 24408 times)

Offline colinbathe

  • Newbie
  • *
  • Posts: 4
    • View Profile
STM32 - IAR Workbench build errors
« on: December 12, 2012, 06:18:01 PM »
Hi,

I've recently been playing with uTasker on STM32F107 on IAR workbench 6.5 and it compiles with the following warnings:

(line numbers may be a little out as I've been playing with the code)

STM32.c 
Warning[Pe111]: statement is unreachable C:\Google Drive\Projects\ST100\uTasker\Hardware\STM32\STM32.c 322


#endif
    return 0;                                                            // we never return....
}
#endif

Expected error - no action required.

Warning[Pe009]: nested comment is not allowed C:\Google Drive\Projects\ST100\uTasker\Hardware\STM32\STM32.c 2001

/*********************************************/

Action - remove leading "/"

Warning[Pa082]: undefined behavior: the order of volatile accesses is undefined in this statement C:\Google Drive\Projects\ST100\uTasker\Hardware\STM32\STM32.c 633

__interrupt void EMAC_Interrupt(void)
{
    while ((ETH_DMAIER & ETH_DMASR) & (ETH_DMAIER_TIE | ETH_DMAIER_TPSIE | ETH_DMAIER_TBUIE | ETH_DMAIER_TJTIE |
                                       ETH_DMAIER_ROTIE | ETH_DMAIER_TUIE | ETH_DMAIER_RIE | ETH_DMAIER_RBUIE |
                                       ETH_DMAIER_RPSIE | ETH_DMAIER_RWTIE | ETH_DMAIER_ETIE | ETH_DMAIER_FBEIE |
                                       ETH_DMAIER_ERIE | ETH_DMAIER_AISE | ETH_DMAIER_NISE)) { // while enabled EMAC interrupt pending

Action: Not sure if this is an issue or not.


http.c 
Warning[Pe546]: transfer of control bypasses initialization of: C:\Google Drive\Projects\ST100\uTasker\stack\http.c 994
            variable "Len" (declared at line 1111 of "C:\Google Drive\Projects\ST100\uTasker\stack\http.c")
            variable "ucPush" (declared at line 1112 of "C:\Google Drive\Projects\ST100\uTasker\stack\http.c")


    for (iSessionNumber = 0; iSessionNumber < NO_OF_HTTP_SESSIONS; iSessionNumber++) {
        if (http_session->OwnerTCPSocket == Socket) {                    // search for the session to handle this event
            switch (ucEvent) {
            case TCP_EVENT_CONREQ:                                       // session requested
                if (http_session->ucState == HTTP_STATE_FREE) {

...

                if (http_session->FileLength > http_session->FilePoint) {
                    MAX_FILE_LENGTH Len = (http_session->FileLength - http_session->FilePoint);
                    unsigned char ucPush = 0;

Action: Not sure if this is a problem or not.


I hope this was useful.

Colin

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3234
    • View Profile
    • uTasker
Re: STM32 - IAR Workbench build errors
« Reply #1 on: December 12, 2012, 08:53:26 PM »
Hi Colin

1) Since main() must return a value, but never actually returns this is a catch 22. If the return is removed there is either another waring or an error. Certainly can be ignored.

2) No idea why IAR says that /**********/ is an illegal nested comment (????) In any case I can't imaging that it is dangerous in any way.

3) This warning is because 2 (or more) volatile registers are being read and operated on. It doesn't matter in which order the code does the reads, the warning will always be given. The registers are declared valatile since their content can change (at any moment) but the bits of interest won't. If the volatile is removed there will be no warning but a new risk of the compiler optimisng something away that it shouldn't (turns a warning into a potentially serious problem). Maybe some reading of volatile registers and placing them into non-volatile storage (with castings) and then the comparison, would quieten the compiler - it probably wouldn't do the code itself any favours though. I don't actually see any risks with the code so I have tended to "thank" the compiler for the indication that there may be a potential problem, check to see whether there could be one and the ignore it if nothing is seen (or ever experienced). I think that this one falls into this category. There are usually pragmas which can be used to disable warning if one is sure that they are nothing serious but these pragmas change between compilers - therefore I tend to accept that there are a certain number of warnings with a particluar build (may also change when new compiler version are installed) and only look again if the number of warnings increases.

4) This one is always flagged. It is due to a slightly wierd use of a case statement in a code area like:

case x:
if (z == 0) {
var abc = 0;
case y:
abc = 1;
}


The
if (z == 0) {
}

area is being used to declare and initialise a variable.
If the code enters at case y: it will be able to use the variable abc (in its context) but it will bypass its initialisation.

However in the code in question the variables that the compiler is warning about are in fact being initialised with different values (appropriate of the code starting at this case) just after the case y: line. Therefore it is true that the initialisation can be bypassed but there is no risk of the initialisation being missed because this is in fact what is wanted from the (slghtly wierd) construction.

Regards

Mark




Offline colinbathe

  • Newbie
  • *
  • Posts: 4
    • View Profile
Re: STM32 - IAR Workbench build errors
« Reply #2 on: December 13, 2012, 03:03:53 PM »
For 2) I should have posted more of the code.

It is basically

/*


/*****/

which it is correctly complaining about.

It should be either

/*



*****/


or better

/*



*/
/*****/

(this is probably one of the most exciting bugs you have had to deal with....  ::) )

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3234
    • View Profile
    • uTasker
Re: STM32 - IAR Workbench build errors
« Reply #3 on: December 13, 2012, 06:21:53 PM »
Hi Colin

Now I see - this bit of code is being used for debuging a strange behaviour of the STM32 USB device (it loses a long word in its FIFO when handling SETUP OUT frames) and so is commented slightly differently in my working version to the release (where it is fully commented out).

Anyway, if
/*********************************************/
is replaced with
*********************************************/
it ensures that the commented out block is a 'pure' comment.

Regards

Mark