| View previous topic :: View next topic |
| Author |
Message |
curt2go
Joined: 21 Nov 2003
Posts: 226
|
|
 Posted: Fri May 02, 2025 10:40 am |
 |
|
Did some more playing around and if i set the float as 1024.XXX it is fine , it declares it properly. If I set it as 2048.XXX it declares it properly. 512.XXX does not work though.
Soooooo weird.... |
|
 |
Ttelmah
Joined: 11 Mar 2010
Posts: 19966
|
|
| Posted: Fri May 02, 2025 11:42 am |
|
|
That suggests it is Prism that is making a mistake on probably one instruction
in the compile.
Post the small program. Your screenshot is too small for me to read it.
I'll see if I can work out what combination gives a good result with it.
However not going to be quick (club event tomorrow, and then a long
trip the next day, so won't be able to get back on the Macs till probably
the middle of the week next week). |
|
|
curt2go
Joined: 21 Nov 2003
Posts: 226
|
|
| Posted: Fri May 02, 2025 12:11 pm |
|
|
Thanks.. I would love to solve it. I will work off the old setup in the time being... Appreciate all the help.
| Code: |
#include <24EP512MC206.h>
#device PASS_STRINGS=IN_RAM
#device adc=12 *=16
#fuses NOJTAG, IESO, PROTECT, NODEBUG,OSCIO
#fuses NOWINDIS, NOIOL1WAY, IESO,FRC_PS//,FRC_PLL
#FUSES WDT //Watch Dog Timer
#FUSES WPRES128 //Watch Dog Timer PreScalar 1:32
#FUSES WPOSTS16 //Watch Dog Timer PostScalar 1:32768 15 // On-chip PLL setting
#use delay(clock=140000000,internal=140000000,restart_wdt)
#include <stdio.h>
#include <stdlib.h>
float version_num = 1.198;
void main(){
delay_cycles(1);
long int i;
} |
|
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19966
|
|
| Posted: Sat May 03, 2025 12:26 am |
|
|
I don't see where this is outputting the float?. Or what the float is?.
If this is being displayed by the debugger in MPLAB, the this is known
sometimes to have issues.
However this cannot be the case, since this is set to NODEBUG.....
You also have the watchdog enabled. Enabling PROTECT wastes chip lives
when developing.
*=16, does nothing on a PIC24, and really you only want the single internal=
declaration, not a separate clock= declaration.
I was expecting to see something setting up a serial port, and printing a
number, to show what is happening.
However big problem is that what you have posted does not give the
hex file you say is correct, on the compiler version you have on an Intel
machine. Thought I would test this since I have a laptop with me, and it
gives a different value to your 'correct' one. Not a good start.... 
Are you dead sure you are using the same compiler version????
There was an issue with PCD, handling floats incorrectly a few versions
ago, and this looks suspiciously like this problem. |
|
|
curt2go
Joined: 21 Nov 2003
Posts: 226
|
|
| Posted: Mon May 05, 2025 8:14 am |
|
|
I was not outputting anything out as the value outputting was the same as what the debugger showed. So for the very small program is was just looking at it in the variables screen.
The other small things in the start i was not too concerned about , but i am glad you pointed out the protect bit. I did not know that one. I will clean somethings up on it and redo it on my end.
I for sure am using the same compiler version. But I will double check everything.
I have tried with multiple version of the compiler with all the same outcome as well. All the way back to 5.103.
I appreciate the help on this. I will repost the files. |
|
|
curt2go
Joined: 21 Nov 2003
Posts: 226
|
|
| Posted: Mon May 05, 2025 8:59 am |
|
|
Verified 5.118 on each machine
** Did another quick test, took the float declaration out and the code compiled the exact same on each machine. Just for some more reference.
Compiled code code from M4 , compiled in Production mode. But DEBUG bit set on. MPLAB 6.25
:080000000002040000000000F2
:100400000FF82700F0FF270020A0B7000000000031
:10041000C1E8A80034152000343A88007400200098
:10042000243A88004827EF0034082C000480880014
:10043000A4E42300148088000E2EEF001E2EEF008F
:100440002E2EEF004E2EEF00000000000040FE00B8
:02000004000AF0
:10AFE0004FFFFF00FFFFFF003FFFFF00DBFFFF0001
:10AFF000F9FFFF00FFFFFF00FFFFFF00FFFFFF0063
:00000001FF
;PIC24EP512MC206
;CRC=2154 CREATED="05-May-25 08:45"
Compiled code from Intel. Not running Seqouia
MPLAB 6.15
:080000000002040000000000F2
:100400000FF82700F0FF270020A0B7000000000031
:10041000C1E8A80034152000343A88007400200098
:10042000243A88004827EF000481250004808800D2
:1004300094F92300148088000E2EEF001E2EEF008A
:100440002E2EEF004E2EEF00000000000040FE00B8
:02000004000AF0
:10AFE0004FFFFF00FFFFFF003FFFFF00DBFFFF0001
:10AFF000F9FFFF00FFFFFF00FFFFFF00FFFFFF0063
:00000001FF
;PIC24EP512MC206
;CRC=8CD0 CREATED="05-May-25 08:56" |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19966
|
|
| Posted: Mon May 05, 2025 10:20 am |
|
|
As a silly thing. Try #OPT 0.
The older maths bug was fixed by that, and this is so similar, that I wonder if
it is related. |
|
|
curt2go
Joined: 21 Nov 2003
Posts: 226
|
|
| Posted: Mon May 05, 2025 10:48 am |
|
|
I had tried that already.. 
Actually i did that in the compiler settings. ill try it in the code directly ...
Nope , no dice.... :( |
|
|
asmallri
Joined: 12 Aug 2004
Posts: 1660
Location: Perth, Australia
|
|
| Posted: Wed May 07, 2025 7:43 am |
|
|
| curt2go wrote: | | Nope cant go to Windows 10 on this. parallels wont let me. Crap. I guess my silicon wont support it. |
You could use UTM and run wiindows 10 x86 on it. I have done this on an M2 Pro but it is slow. I am going to try Crossover next.
_________________
Regards, Andrew
http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!! |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19966
|
|
| Posted: Wed May 07, 2025 7:46 am |
|
|
The code as posted:
| Code: |
#include <24EP512MC206.h>
#device PASS_STRINGS=IN_RAM
#device adc=12 *=16
#fuses NOJTAG, IESO, PROTECT, NODEBUG,OSCIO
#fuses NOWINDIS, NOIOL1WAY, IESO,FRC_PS//,FRC_PLL
#FUSES WDT //Watch Dog Timer
#FUSES WPRES128 //Watch Dog Timer PreScalar 1:32
#FUSES WPOSTS16 //Watch Dog Timer PostScalar 1:32768 15 // On-chip PLL setting
#use delay(clock=140000000,internal=140000000,restart_wdt)
#include <stdio.h>
#include <stdlib.h>
float version_num = 1.198;
void main(){
delay_cycles(1);
long int i;
}
|
Does not give the hex file you post, for me, on either OS. I get:
| Code: |
:080000000002040000000000F2
:100400000FF82700F0FF270020A0B7000000000031
:10041000C1E8A80034152000343A88007400200098
:10042000243A88004827EF000481250034808800A2
:1004300094F92300448088000E2EEF001E2EEF005A
:100440002E2EEF004E2EEF000030EF0000000000D7
:040450000040FE006A
:02000004000AF0
:10AFE000CFFFFF00FFFFFF00BFFFFF00DBFFFF0001
:10AFF000F9FFFF00FDFFFF00FFFFFF00FFFFFF0065
:00000001FF
;PIC24EP512MC206
;CRC=C1E5 CREATED="07-May-25 14:10"
|
With 5.118, In both environments. Which is not actually the correct
conversion for 1.198.
However trying some different numbers does intermittently give
different results between the configurations.
I suspect what is happening is that CCS somewhere in their code
is using an instruction sequence that Prism is not correctly emulating.
Now you could possibly try installing conventional Windows, rather than
Windows ARM, and running this inside an emulation. i did this a while
ago, when having another issue with Prism. Performance will drop,
but it may well let CCS work.
The details of how to do this are here:
[url]
https://www.intego.com/mac-security-blog/how-to-run-windows-11-for-free-on-an-m1-m2-m3-or-m4-mac/
[/url]
Look at the section about using emulate.
Key here is that you actually run Intel Windows, inside the emulation,
instead of running Windows ARM, and then emulating the app inside
this.
It looks as if at present the use of CCS inside the Prism emulation is
problematic. |
|
|
curt2go
Joined: 21 Nov 2003
Posts: 226
|
|
| Posted: Wed May 07, 2025 8:52 am |
|
|
Thank you for looking into this.
Not really an option right now to rebuild in the windows emulation (x86) i did think about that before getting to the point I am at right now.
I have went back to my old computer for now.
Should I be pressing CCS to fix this bug? Or can they even fix this?
Thank you again for digging into this. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19966
|
|
| Posted: Wed May 07, 2025 11:02 am |
|
|
I doubt if it is their bug.
It is with the emulation handling in Windows ARM. Might be worth raising
with MicroSoft. |
|
|
curt2go
Joined: 21 Nov 2003
Posts: 226
|
|
| Posted: Wed May 07, 2025 12:02 pm |
|
|
Oh, ok.
I sent off the info to CCS... Ill see what they can come up with. If anything.
That being said, it would be easier for CCS to do a work around than think Microsoft is ever going to even care. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19966
|
|
| Posted: Thu May 08, 2025 12:29 am |
|
|
Two way thing there. MS, want the Prism emulation to be as good as
possible, so will want to know if a particular machine instruction is not
being emulated correctly. Really is does need to be fixed.
Now CCS, if you can send them the exact source, and the values that
result, may be able to work out what instruction they are actually using
that causes this. However understand that their code is not written
in machine language, but is being generated by a compiler. Hence it'd
be the compiler authors, who really need to be talked to.
The fact it actually behaves differently on mine, suggests the exact ARM
chip involved may be important too. I don't have a MacBook, all of mine
are 27" desktop machines, except the M4, which is a 24" with the 10core
M4 Pro. Now though the chips are all described as M4, you will always find
hidden differences at some point. There may be some hidden change that
affects how Prism is functioning.
I'll refer it into the MicroSoft developer chain, with some example code
and see if they come back with anything. |
|
|
curt2go
Joined: 21 Nov 2003
Posts: 226
|
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
