|
|
View previous topic :: View next topic |
Author |
Message |
Ttelmah
Joined: 11 Mar 2010 Posts: 19215
|
|
Posted: Tue Jan 07, 2020 1:28 pm |
|
|
Sadly, 8.92 was the last release of 'MPLAB'. After this they switched to
MPLAB-X. This is based on the JellyBeans engine. It took about a hundred
releases before it even became remotely competent. Even now, it is a very
poor environment. For all chips supported by 8.92, I too use this. However
for newer chips if you want to use MPLAB, you have to use MPLAB-X.
So if I need an MPLAB feature I have to use MPLAB-X.
The CCS IDE can use most MicroChip debuggers (you have to have
MPLAB loaded to do this), and runs better, but it has some really major
limitations (for example, won't allow you to access ROM beyond what is
loaded in the source - makes it impossible to debug your own code that
accesses the program memory). |
|
|
asmallri
Joined: 12 Aug 2004 Posts: 1630 Location: Perth, Australia
|
|
Posted: Tue Jan 07, 2020 2:53 pm |
|
|
Ttelmah wrote: | Sadly, 8.92 was the last release of 'MPLAB'. After this they switched to
MPLAB-X. This is based on the JellyBeans engine. It took about a hundred
releases before it even became remotely competent. Even now, it is a very
poor environment. For all chips supported by 8.92, I too use this. However
for newer chips if you want to use MPLAB, you have to use MPLAB-X.
So if I need an MPLAB feature I have to use MPLAB-X.
The CCS IDE can use most MicroChip debuggers (you have to have
MPLAB loaded to do this), and runs better, but it has some really major
limitations (for example, won't allow you to access ROM beyond what is
loaded in the source - makes it impossible to debug your own code that
accesses the program memory). |
I completely agree.
CCS does not support the PIC32 families. For PIC32 projects I used the Microchip development environment. However the MPLAB-X environment combined with the incomprehensible "harmony" libraries for the PIC32 created such a poor development experience that I spent more than double the amount of time time developing a project on the PIC32 platform than the same project on a PIC24/dsPIC platform. As a result, I stopped all PIC32 development and moved to an alternative vendors for 32 bit processors.
If CCS supported the PIC32 family I may have stayed with the PIC32 processor but I do not regret moving. Today I have both MPLAB and MPLAB-X environments but, if at all possible, I use MPLAB over MPLAB-X. _________________ Regards, Andrew
http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!! |
|
|
jeremiah
Joined: 20 Jul 2010 Posts: 1315
|
|
Posted: Tue Jan 07, 2020 3:26 pm |
|
|
allenhuffman wrote: | Actually, even with my printf disabled, I still end up with things at that end memory range. What are they called? I need to poke around in the manual and see what else adds stuff there in my C code. |
Without seeing a small recompileable example, it would be hard to help you out. Can you start with a copy of your program and take out a bunch of stuff until you whittle it down to something small that can be evaluated? If not, you may have to send a copy to CCS support and ask them what is causing the fuse changes. |
|
|
temtronic
Joined: 01 Jul 2010 Posts: 9097 Location: Greensville,Ontario
|
|
Posted: Tue Jan 07, 2020 5:31 pm |
|
|
just throwing this out ...
re:
I'm trying to track down where these settings are coming from. If it's only possible to set the using #FUSES, I will focus there.
:020000040005F5
:1057F0000000FF00FFFFFF00FB87FF005F77FF0057
:00000001FF
I don't use that PIC but I'd start reading the Microchip datasheet to see what memory locations the above code refers to. Once you KNOW the locations, then decode the data. My gut tells me they could be 'ID' information, 'Serial Number', perhaps die revision ?? If you can't figure it out, ask Microchip what they're for. They've always helped me in the past both by email and old fashion landline !
There's another possible 'gremlin'.... If you're using an ICD or debugger or some 'smart' programmer, that could be altering 'FUSES' or the PIC 'CONFIG' as IT sees fit to run. |
|
|
newguy
Joined: 24 Jun 2004 Posts: 1900
|
|
Posted: Tue Jan 07, 2020 5:58 pm |
|
|
asmallri wrote: |
CCS does not support the PIC32 families.
...
If CCS supported the PIC32 family I may have stayed with the PIC32 processor... |
I actually asked CCS recently if they were planning to support the PIC32 family but the answer was (from memory, forgive me if I paraphrase a bit) that they are waiting to see what happens to that family as now that Microchip has acquired Atmel, that they feel that Microchip will abandon that line in favour of Atmel's equivalents. |
|
|
asmallri
Joined: 12 Aug 2004 Posts: 1630 Location: Perth, Australia
|
|
Posted: Tue Jan 07, 2020 6:26 pm |
|
|
newguy wrote: | asmallri wrote: |
CCS does not support the PIC32 families.
...
If CCS supported the PIC32 family I may have stayed with the PIC32 processor... |
I actually asked CCS recently if they were planning to support the PIC32 family but the answer was (from memory, forgive me if I paraphrase a bit) that they are waiting to see what happens to that family as now that Microchip has acquired Atmel, that they feel that Microchip will abandon that line in favour of Atmel's equivalents. |
The Atmel SAMD21 is my current 32bit goto processor :-) _________________ Regards, Andrew
http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!! |
|
|
asmallri
Joined: 12 Aug 2004 Posts: 1630 Location: Perth, Australia
|
|
Posted: Tue Jan 07, 2020 6:37 pm |
|
|
allenhuffman wrote: | Should the .hex file contain anything at the FUSES location (end of flash) when you use #FUSES none?
I'm trying to track down where these settings are coming from. If it's only possible to set the using #FUSES, I will focus there.
:020000040005F5
:1057F0000000FF00FFFFFF00FB87FF005F77FF0057
:00000001FF |
Looks like config fuses. It is very easy to prove it. Copy the lines to a text file, Open MPLAB, select the processor that you are using. Open the config setting tab and note the settings. Import the hex file and look again at the fuse settings. _________________ Regards, Andrew
http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!! |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19215
|
|
Posted: Wed Jan 08, 2020 1:55 am |
|
|
allenhuffman wrote: |
Should the .hex file contain anything at the FUSES location (end of flash) when you use #FUSES none?
I'm trying to track down where these settings are coming from. If it's only possible to set the using #FUSES, I will focus there.
:020000040005F5
:1057F0000000FF00FFFFFF00FB87FF005F77FF0057
:00000001FF
|
Tell us what chip?.
Then we can have a chance of knowing what this is.
Also the environment?. Normal chip?. Debugging?.
Remember MPLAB defaults to building for DEBUG.
If the latter, then this is what is setting the fuse.
If a chip is programmed to DEBUG, the watchdog has to be disabled,
and the DEBUG fuse set. This will automatically be done. |
|
|
temtronic
Joined: 01 Jul 2010 Posts: 9097 Location: Greensville,Ontario
|
|
Posted: Wed Jan 08, 2020 5:33 am |
|
|
re: ,,,Remember MPLAB defaults to building for DEBUG.
you can change the default to become 'RELEASE'. uChip changed MPLAB around 8.5x after I talked to them. One of their SW gurus called,responding to my email and couldn't believe I don't use 'debug'. I told him I've always debugged in the Real World,after all that's where the PIC HAS to run. |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19215
|
|
Posted: Wed Jan 08, 2020 6:44 am |
|
|
Agreed, but I'm looking for things that 'might' be setting a fuse... |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|