Group Actions
Engagement
  • Author Author: cmelement14
  • Date Created: Date Created
  • Views 631 views
  • Likes 5 likes
  • Comments 5 comments
Related
Recommended

Do Not Hide the Problem - A Correct SW Lab 7 Solution

cmelement14

image

 

 

SW Lab 7 Problem Description

 

Like other people reported here and there, I noticed the same problem in Experiment 2, SW Lab 7: the peripheral test application stuck at the point of showing message "Running Interrupt Test  for psu_csudma..." (shown in the screenshot below).

image

 

However, we did a similar peripheral test application in Experiment 3, SW Lab 5. The only difference between them is: in lab 5, the build configuration is Debug while in lab 7 the build configuration is Release. In lab 5, the test completed successfully (as shown in the screenshot below).

image

 

What's the difference between Release configuration and Debug configuration? A couple of major differences: with and without compiler optimization AND without and with debugging information. With and without debugging information should usually NOT make any behavior change. Thus, I think the problem is due to the optimization for Release configuration and the Debug version has no problem just like Experiment 3, SW Lab 5. To confirm the problem doesn't exist in Debug configuration, I slightly modified the Create Boot Image settings regarding the folder path of application binary: before the modification, we use the binary from the release folder and then we changed it to the debug folder (Please refer the highlighted difference in the following two screenshots). The test result confirmed that the BOOT.bin using the debug version application code had successfully completed the whole test.

image

 

image

 

I didn't use the solution provided in the training materials, but in P2P: SW Lab 7 Road Block blog, reported the provided solution basically hides the problem (maybe because the lab creator observed the same problem and couldn't find a solution). It is very common in embedded development that a working debug version of application code stops working after switching to a release version. Usually it's because of the compiler optimization.

 

 

A Correct SW Lab 7 Solution

 

Let's take a look at the highlighted line 244 shown below. What do you think the compiler optimization will do for that line? It will generate assembly code that reads the variable DsDone just once and uses this value to check the condition (i.e., DsDone == 0) forever. It will NOT update DsDone. The reason is because the compiler optimizer considers variable DsDone doesn't change at all in the context. However, as programmer, we know the variable has to change somewhere else. Otherwise, this is a dead loop which is definitely not the programmer's intention.

image

 

How can we let the optimizer know our intention? Here's the solution - adding keyword volatile before the declaration of variable DsDone (as highlighted below). Basically, the keyword tells the optimizer not do any optimization in any reference to variable DsDone.

image

 

Test result confirmed the BOOT.bin including the above modification had successfully completed the whole peripheral test. Hope I clearly explained the problem and the solution. Please comment with your feedback or questions.

  • in reply to cmelement14

    Of course, I know the compiler / optimizer are not sentient, but I was simply mirroring some of the wording in your blog post. I'm just surprised that optimizer rulesets prioritize variable optimization before considering the "while" syntax, thus creating this dead loop. It seems more intuitive that the optimizer should prioritize intended implementation given by the source syntax before trying to optimize, but perhaps this is too limiting on what optimizations can be done.The links you provided were very helpful. Thanks for adding those.

  • in reply to aspork42

    I definitely noticed that the fan stopped when running this test. I suspected the temperature would go very high, so every time after running the application, I unplugged the power and didn't let it run very long time at all. That's why my board's temperature didn't go as high as yours.

     

    Sorry, I forgot to mention this and hope no damage to your board.

  • Great write up - I just found this last night. The part that worried me about it is that running this test disables the fan. The processor then deadlocks and turns into a little heater.

     

    I ended up with the error messages shown here:

    Temperature Alarm(0) HIGH Threshold is 52.700 Centigrade.

    Temperature Alarm(0) LOW Threshold is 42.698 Centigrade.

    VCCINT Alarm(1) HIGH Threshold is 0.637 Volts.

    VCCINT Alarm(1) LOW Threshold is 1.037 Volts.

    VCCAUX Alarm(3) HIGH Threshold is 1.597 Volts.

    VCCAUX Alarm(3) LOW Threshold is 1.997 Volts.


    Alarm 0 - Temperature alarm has occured


    The Current Temperature is 63.075 Centigrade.

    The Maximum Temperature is 63.658 Centigrade.

    The Minimum Temperature is 62.516 Centigrade.

     

    So the MPSoC was over 10 Deg C higher than its threshold... Hopefully nothing got cooked too badly.

     

    I can see you had this in your screenshot as well; but it wasn't as hot as mine got...

  • in reply to nerdyupdates

    Please remember compiler itself doesn't have any intelligence so it doesn't understand programmer's intention. It does optimization based on rules given by the creator of the compiler.

     

    Ok, let's first check what's the programmer's intention by the following statement

    while(DsDone == 0);

    I am pretty sure you agree on this: the programmer wants to read DsDone all the time until its value is not 0 any more, then the execution continues to the next statement.

     

    However, compiler doesn't know it needs to create code that reads DsDone all the time. Instead, the given optimization rule may say if there's no assignment statement like the following

    DsDone = value;

    before checking the condition again, it doen't need to read the variable DsDone again. Thus, DsDone will be always 0 and the while statement becomes a dead loop.

     

    If we declare DsDone with modifier (AKA qualifier) keyword volatile which tells the compiler that the value of DsDone will change all the time, the compiler will ignore the above mentioned rule and generate code that read DsDone again before checking the condition again.

     

    If I didn't explain clearly, please refer to the following links for more explanation

    https://barrgroup.com/Embedded-Systems/How-To/C-Volatile-Keyword

    https://www.geeksforgeeks.org/understanding-volatile-qualifier-in-c/

  • Nice investigation into this. Thanks for sharing your knowledge on compiler optimization.

     

    One question which may not have a simple answer, but why is the "while" statement not enough for the compiler to know the programmer's intent even though the "DstDone" variable was not originally declared volatile? Seems almost like the compiler is making an improper optimization by ignoring the while altogether.