Changing Device Type doesn't work

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

I am working in Microchip Studio v7.02542.  My project was created for the ATTiny441 and has been working successfully.  Now I tried changing the device type to the ATMega328P for my Arduino Uno from the Project Properties->Device menu.  The type successfully changes in Properties:Device:Current Device.  However, the compilation still targets the 441.  I can see this throughout the "Toolchain" menu and the build output as the mcu still specifies the 441.

 

* Toolchain:AVR/GNU Common/General:Target Device: "-mmcu=attiny441 -B "$(PackRepoDir)\atmel\ATtiny_DFP\1.8.332\gcc\dev\attiny441"

 

I've tried cleaning and rebuilding my solution and reopening Microchip Studio but the mcu never updates.

 

Out of frustration I ported my project to MPLABX and changing the target device via the same process works to correctly define -mmcu.  However, I then have a different problem.  Compilation succeeds for the ATTiny441 but fails for the 328P as the registes are no longer defined.  This appears to be because the makefile defines __ATtiny441__/__ATmega328P__ while io.h requires __AVR_ATmega328P__/__AVR_ATmega328P__ to include include iotn441.h/iom328p.h.  However, I'm not clear why the 441 does work while the 328P does not.

 

Any device on both issues?  Thanks much!

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

You can change the Device in AS7.0.   It works fine.

 

If you have a problem,  ZIP up the particular project.   Attach the ZIP file.

Then readers can replicate the issue.   And if there is a genuine problem,  we can report it to the AS7.0 Developer Team.

 

I have never used ATtiny441.   It is possible that there is an error in the Device Pack data.

 

David.

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

Thanks David.  I was able to reduce both issues with minimal projects and attached both.

 

Regarding the Microchip Studio issue where changing devices didn't build for the correct target, I created a new Microchip studio project and I can change devices on this one.  Further, I can't get this one to not take the new device.  Maybe you'll see something obvious in the attached project.

 

I also tried creating a new project in MPLab and this did not fix the failed compilation due to missing register definitions.  When configured for the ATTiny441, compilation works.  When configred for the ATMega328P, compilation fails as DDRA is not found.

 

Also, do you know where the __AVR_targetname__ is defined that is used in io.h?

 

Greatly appreciate your help!

Best regards,

Dan

Attachment(s): 

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

When configred for the ATMega328P, compilation fails as DDRA is not found.

And that's correct, have you looked at the 328's datasheet? Does it have a PORTA?

John Samperi

Ampertronics Pty. Ltd.

https://www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

danikes wrote:

Also, do you know where the __AVR_targetname__ is defined that is used in io.h?

When you specify the Target device in the AS7.0 GUI -mtargetname is sent as argument to GCC.

GCC Compiler generates the macro __AVR_targetname__

 

Subsequent <avr/io.h> uses this macro to to pull in the target specific header file.

 

Since your example project does not even include <avr/io.h> there is no way that it could know any special function registers or even general C features.

 

Yes,  it is wise to reduce any problem down to a minimal size but you still need to do something.

No,  I have not looked at the MPLABX project.

 

David.

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

Thanks John.  You were correct.  Seems obvious now but this resulted from the confusion with Microchip Studio not changing the target device.  The project would compile successfully in Microchip Studio for the ATTiny and the ATMega but not in MPLAB.  So I had dismissed the port definitions as the source of the problem in MPLAB.  In reality, Microchip Studio was silently not changing the device type so it hid the failing definitions.  Now I'm porting the project to support the ATMega, a fairly signficant task.

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

david.prentice wrote:

Since your example project does not even include <avr/io.h> there is no way that it could know any special function registers or even general C features.

 

I simply don't believe you.    Post a genuine AS7.0 (Microchip Studio) project.

Then we can attempt to "change device" for ourselves.

 

I often change target device when writing "universal" code.

You can see the resultant generated code by viewing the LSS file.

 

David.

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


David,

 

Not sure what else to provide you.  I posted the project that replicates the behavior.  I just downloaded it from this thread and verified it again.  Did you try it?  Steps to reproduce:

1. Unzip ChangeDeviceType.zip and open in Microchip studio

2. Verify current device:

3. Build.  Note mcu type.

        "C:\Program Files (x86)\Atmel\Studio\7.0\toolchain\avr8\avr8-gnu-toolchain\bin\avr-gcc.exe"  -x c -funsigned-char -funsigned-bitfields -DDEBUG  -I"C:\Program Files (x86)\Atmel\Studio\7.0\Packs\atmel\ATtiny_DFP\1.8.332\include" -I"../HAL" -I"../DRV" -I"../src"  -Og -ffunction-sections -fdata-sections -fpack-struct -fshort-enums -g2 -Wall -mmcu=attiny441 -B "C:\Program Files (x86)\Atmel\Studio\7.0\Packs\atmel\ATtiny_DFP\1.8.332\gcc\dev\attiny441" -c -std=gnu99 -MD -MP -MF "src/main.d" -MT"src/main.d" -MT"src/main.o"   -o "src/main.o" "../src/main.c" 

 

4.  Change Device type.  

 

5. Note that device type used in build has not changed.

       "C:\Program Files (x86)\Atmel\Studio\7.0\toolchain\avr8\avr8-gnu-toolchain\bin\avr-gcc.exe"  -x c -funsigned-char -funsigned-bitfields -DDEBUG  -I"C:\Program Files (x86)\Atmel\Studio\7.0\Packs\atmel\ATtiny_DFP\1.8.332\include" -I"../HAL" -I"../DRV" -I"../src"  -Og -ffunction-sections -fdata-sections -fpack-struct -fshort-enums -g2 -Wall -mmcu=attiny441 -B "C:\Program Files (x86)\Atmel\Studio\7.0\Packs\atmel\ATtiny_DFP\1.8.332\gcc\dev\attiny441" -c -std=gnu99 -MD -MP -MF "src/main.d" -MT"src/main.d" -MT"src/main.o"   -o "src/main.o" "../src/main.c" 

 



 

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


I'd suggest there's something "broken" in that solution file. I think I'd just create a whole new solution and re-add all the source files to it (you could even then diff it to spot what's different). If I simply create a new proj/solution set to 441:

Build:

Change:



Build:

 

Then -mmcu= switches over as expected. If you see something else then something is broken!

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

Your ChangeDevice.zip contains a project called O2Sensor.cproj with the only source file called main.c

int main(void)
{
    return 0;
}

 

Since it does not include "avr/io.h" it will know nothing about the Special Function Registers of the ATtiny441

 

Your MissingRegisterDefinitions.X.zip with the only source file called main.c

/*
 * File:   main.c
 * Author:
 *
 * Created on July 1, 2022, 6:00 PM
 */

#include <xc.h>

int main(void) {
    
       DDRA = 0;    //Set bits = output

    return 0;
}

 

It does include "xc.h".  So it will know about the Special Function Registers of the ATtiny441.

And since the ATmega328P chip does not have a SFR called DDRA it will give an error.  (if you change device)

But works on the tiny441.   (which does have DDRA according to I/O window in Simulator)

 

If you run the Simulator in AS7.0 you can inspect the Disassembly.

 

If you want to post a real project you could simply run a timer or blink an LED.   i.e. anything that is non-trivial.

 

David.

 

 

Last Edited: Fri. Jul 8, 2022 - 03:39 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1


I missed the fact that there was a ChangeDeviceType.zip above so I just downloaded and tried switching 441 to 328P and it still built for 441.

 

So as I had also created my own project/solution I tried diffing things and now I see what the issue is.

 

Up to now I don't think it had been mentioned that rather than the standard build configurations of Debug and Release this problematic project/Solution has had another config added called "O2". I only noticed this because of:

 

 

So I think what's going on is that the device type is being changed for one build configuration but then a different one is being built.

 

So in "Configuration Manager" I see:

 

 

So the "active" (and hence the one that will build) is "Debug". But there are also H2 and O2 (and Release) configs there too. Now in:

 

 

This is kind of curious - why does it say "N/A" ? Is the implication of that, that changing device changes ALL configs at once? If so why does "Configuration:" even appear on this screen?

 

There might be a bug here that "Change Device" can nly do so for Debug/Release but is confused by other build configs?

 

Another thing I just noticed is:

 

My project is on the right, the OP's on the left. as far as I know one might expect all three fields to be the same so where does "blinky" come from?

 

Did this solution start as "blinky" and then the .cproj files have been hand edited or something?

 

I tried editing the XML and switching "blinky" back to "O2Sensor" but sadly that does not seem to have helped either.

 

As I said previously I think I'd simply start with a whole new solution. Make sure you can switch 441-328P back and forth and it builds for each. Then use Config to add "H2" and "O2" and see if it is something about doing so that then breaks the 441-328P transition. Or you may just find it all works. If that is the case then do DIFF this broken solution with the one that works and see if you can spot what in the XML is different and causing the problem

 

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

I am guessing that the OP actually wants to read an Oxygen Sensor.    Hint.   Project name.

 

There are some projects that never need "io.h" or "xc.h" e.g. if you just include the library header file.

For example.   A Codevision project might include the library "alcd.h" and make appropriate LCD calls.

(the LCD hardware is configured by the Codevision GUI)

 

But with most microcontroller projects the user accesses the chip hardware at some point.  e.g. the DDRA statement.

And the User has probably configured the library settings via the GUI.

 

It is important to know when and where you include header files.

And depending on the IDE,  how and where you configure and link with library files.

 

David.

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


Thanks for all of the great responses! 

 

First, there were two distinct issues.  One in regards to changing the MCU in Microchip Studio.  That led me to try porting to MPLAB where I had compilation issues due to missing register definitions.  The second was resolved.  The only remaining issue is changing MCU types in Microchip Studio.

 

Second, clawson, in post #3 I mentioned that I had created a new project and it worked correctly.  So the problem was soley with my original project that I was able to reduce down to ChangeDeviceType.zip. 

 

Third, your observations are all correct:

  • I am talking to an Oxygen sensor.  And soon also to a Hydrogen sensor.
  • I did create a new configuration called O2 but then dropped it.  As I don't see an easy way to remove configurations, I just left it.  Is there an easy way?
  • This project did start off as a project named Blinky given to me by my HW guy and I renamed it O2Sensor.  I believe I just right clicked on the project name and renamed it as follows so I'm not sure how that legacy "blinky" stuck around.

 

Now I see that the device type is only changed for Configuration:N/A.  No idea why but great catch.  Does seem suspicious.



Fourth, David, I believe your post #12 was in regards to the missing registers which has been resolved but just to follow up.  I have not included any libraries, but you're right that I didn't include io.h.  My bad!  But the problem was that the registers were completely different but I was lulled into not-believing that by the fact that my Microchip studio project compiled for both micros.  As we all now though, it was only compiling for the ATTiny. 

 

I have been using a new project without issue so I'm willing to just chalk this up to solar flares and my new-ness to Microchip Studio.

 

Side note.  I have many years of embedded experienece with ARM products but am brand new to the world of Atmel/Microchip.  There are a LOT of rough edges, no doubt because I'm new.

  • Microchip vs MPLAB IDE - I couldn't find a straight answer on which to start with, despite a lot of searching.
  • It is not clear which includes to use with which micros. Now I'm also building for the Curiosity Nano (with AVR128DA48) which uses ioavr128da48.h.  But again, I'm not clear how this gets included.  Do I need io.h for all micros?
  • Odd mcu behavior as discussed above.  
  • Device pack manager - I updated a few packs along the way but I'm not clear if I needed to.
  • Fuses.  Specifically the need for the high voltage programmer and why this is needed at all.

 

I'm sure these become clearer with experienece but they were not obvious to me just starting out!  Thanks again for all of your help.

 

 

 

 

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

 

I've spent far too long looking at this problem that is good for me. My conclusion: The Solution & project are broken. I cannot change the Device Pack and I'll guess this is why none of us can change from tiny to mega

 

 

There's virtually nothing in this project that won't take 2 minutes to regenerate. So that's my recommendation.

 

 

Last Edited: Sat. Jul 9, 2022 - 08:31 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yup, clearly there's something corrupt in the XML in the cproj. I fear only Atmel /Microchip (who can look behind the scenes at what is actually happening when yup "change device") could actually tell you WHAT is wrong in the XML. Perhaps they'll read this thread or maybe you need to open a support ticket. It would be good to understand what you did to corrupt it so it can be avoided in future.

 

By the way did you ever edit the XML by hand?