DSPIC33E and Fast Math

Post
ssparrow
New Member
2011/12/13 05:39:44
After moving recently from dspic33f to dspic33e, we have come unstuck with a number of problems what seems to be the compiler, linker library and real-ice related.
 
Compiler is 3.30c and MPLAB version was 8.80, but we had problems when SFR registers window shown, so we rolled back to MPLAB 8.76.
We also use Real-Ice as the debugger / programmer.
 
We are experienceing problems with the fast-math libraries (which worked ok on dspic33f) :
C:\Program Files\Microchip\MPLAB C30\lib\libfastm-coff.a(sinfx.epo)(.libmx+0x2):libmx.inc: undefined reference to `PSVPAG'
C:\Program Files\Microchip\MPLAB C30\lib\libfastm-coff.a(sinfx.epo)(.libmx+0x6):libmx.inc: undefined reference to `PSVPAG'
C:\Program Files\Microchip\MPLAB C30\lib\libfastm-coff.a(sinfx.epo)(.libmx+0x2a):libmx.inc: undefined reference to `PSVPAG'
C:\Program Files\Microchip\MPLAB C30\lib\libfastm-coff.a(sinfx.epo)(.libmx+0x74):asm.s: undefined reference to `PSVPAG'
C:\Program Files\Microchip\MPLAB C30\lib\libfastm-coff.a(sinfx.epo)(.libmx+0xc4):asm.s: undefined reference to `PSVPAG'
C:\Program Files\Microchip\MPLAB C30\lib\libfastm-coff.a(sinfx.epo)(.libmx+0xc8):asm.s: more undefined references to `PSVPAG' follow
It does not seem to be DSPIC33E aware ? If we had access to the source, we could recompile to fix this.
 
We had to rebuild the libpic30.a library due problems picking up crt0_extendedep.o, it kept picking up crt0_standard
If must use the legacy libraries option or we get the following errors:
undefined reference to `strftime'
undefined reference to `_Aldata'

We cannot use software breakpoints a they appear to corrupt the code, are VERY slow and behave erratically; We are stuck with hardware breakpoints for now and have to tolerate skidding.
 
I have trolled the forums and support section, but it seems we are the only ones experiencing these problems.
We also lodged a ticket on the software breakpoints issue (about a week ago, but still no response).
 
It seems we are at the bleeding edge here.. but I would appreciate a response o some sort to help or indication of whether these problems are being (or have been) addressed in upcoming releases as i is very frustrating right now.
 
Steve.
cawilkie
Administrator
Re:DSPIC33E and Fast Math 2011/12/13 09:52:56
Steve,

  I'm sorry you had issues with libfastm, we will look into it for the coming release.  Unfortunately there are some libraries that ship with C30 that we are not permitted to send the source for, libfastm is one of those.  I understand that this is frustrating.

  There is an easy 'work-around' for the libfastm, PSVPAG and DSRPAG are the same register just renamed for EP devices.  If you would like, you may temporarily add _PSVPAG = 0x34  and PSVPAG = 0x34 to the linker script, near where _DSRPAG and DSRPAG are defined.

W.r.t the libpic30 picking up crt0_standard, which device were you compiling for?  If you are using a custom linker script, it would be nice to see it. 

  When using the legacy-libc option (which does not effect the floating point libraries), did you recompile your entire source base?  This may be due to using your own libpic30, this needs to be also compiled with the legacy libc option (note that there are two versions of this in the lib directory).

Regards
Calum
ssparrow
New Member
Re:DSPIC33E and Fast Math 2011/12/13 17:49:36
Hi Calum,
 
I appreciate the response.
We will give the PSVPAG renaming suggestion a go; were it to work, it would be of tremendous help. The fast match libaries are indeed FAST.
 
For the crt0_extended issue, we were compiling for the DSPIC33EP512MU810 device. No matter what we tried, the linker would always refer to the crt0_standard version (even though the default link file at the top has the following:
OUTPUT_ARCH("33EP512MU810")
CRT0_STARTUP(crt0_extendedep.o)
CRT1_STARTUP(crt1_extendedep.o)
With respect to the libpic30 libary, we had to rebuild it to overcome the crt0_extended/standard issue above. I could not find another workaround. Nothing was changed, we just loaded the workspace libpic30.mcw and built it. Once the new library was generated, we added ito the library list in our own project.
 
Do you have any comments on the software breakpoints issue I mentioned ? The problem ticket I lodged is no longer there and I received no response from Microchip on the issue.
 
Regards,
Steve
 
cawilkie
Administrator
Re:DSPIC33E and Fast Math 2011/12/14 08:40:14
Steve,

   I will ask about the software breakpoints; not really my area of expertise but I can certainly do some digging.

   With this extra information about the library issue, we will look into that.

   v3.31 will be released (normally I would say 'shortly', but the only certainty is that it WILL be released).  The fast math library has a few repairs, including:
    *) EP support improved
    *) Exch errata implemented in errata versions of libraries
    *) Improved behaviour for very small numbers in the double precision

Regards
Calum

Regards
Calum
shibanifa
Junior Member
Re:DSPIC33E and Fast Math 2011/12/14 15:42:33

Hi Steve,

Are you referencing __reset in your code?
Regards,
Farah
ssparrow
New Member
Re:DSPIC33E and Fast Math 2011/12/14 17:59:38
Calum,
 
I look forward to more news on the upcoming 3.31 release and anything you can dig up on software breakpoints.
 
While debugging yesterday on DSPIC33EP512MU810 device, I also found another "quirk"; maybe worthy of another thread, but thought I'd run it past you first. If not a known issue, I'll lodge it as a compiler bug. 
 
I had short enums turned on for the compiler using the -fshort-enums.
I had three type-def'd variables as follows:
static  SPI_MODE_T          SPI2_LastMode;
static  SPI_SPEED_T         SPI2_LastSpeed;
static  SPI_SIZE_T           SPI2_LastSize;
When I updated the second variable, the first was also being updated!!
 
The compiler generated the following code:
SPI2_LastMode   = SPI_MODE_INV;                             // Force configuration
 20484  B3C631     mov.b #0x63,0x0002
 20486  23A430     mov.w #0x3a43,0x0000
 20488  784801     mov.b 0x0002,[0x0000]
144:                   SPI2_LastSpeed  = SPI_CLK_INV;
 2048A  23A420     mov.w #0x3a42,0x0000
 2048C  784801     mov.b 0x0002,[0x0000]
145:                   SPI2_LastSize   = SPI_SIZE_INV;
 2048E  23A410     mov.w #0x3a41,0x0000
 20490  784801     mov.b 0x0002,[0x0000]
 
Nasty... the compiler was trying to do byte-wide updates ! Needless to say. the -fshort-enums option is now off.
 
One last thing...
When trying to move data from DMA buffers defined in _eds_ space, to working memory, the memcpy() failed without throwing any warnings; it is not eds-aware and the compiler does not realise these are different memory spaces.
I dug around in the libpic30 code and found a _memcpy_eds function which I managed to get working for the purpose. This is not documented anywhere that I can see, but useful nonetheless.
 
Regards,
Steve
 
 
 
 
cawilkie
Administrator
Re:DSPIC33E and Fast Math 2011/12/16 10:56:10
ssparrow

Calum,
 
I look forward to more news on the upcoming 3.31 release and anything you can dig up on software breakpoints.
 
While debugging yesterday on DSPIC33EP512MU810 device, I also found another "quirk"; maybe worthy of another thread, but thought I'd run it past you first. If not a known issue, I'll lodge it as a compiler bug. 
 
I had short enums turned on for the compiler using the -fshort-enums.
I had three type-def'd variables as follows:
static  SPI_MODE_T          SPI2_LastMode;
static  SPI_SPEED_T         SPI2_LastSpeed;
static  SPI_SIZE_T           SPI2_LastSize;
When I updated the second variable, the first was also being updated!!
 
The compiler generated the following code:
SPI2_LastMode   = SPI_MODE_INV;                             // Force configuration
 20484  B3C631     mov.b #0x63,0x0002
 20486  23A430     mov.w #0x3a43,0x0000
 20488  784801     mov.b 0x0002,[0x0000]
144:                   SPI2_LastSpeed  = SPI_CLK_INV;
 2048A  23A420     mov.w #0x3a42,0x0000
 2048C  784801     mov.b 0x0002,[0x0000]
145:                   SPI2_LastSize   = SPI_SIZE_INV;
 2048E  23A410     mov.w #0x3a41,0x0000
 20490  784801     mov.b 0x0002,[0x0000]



I must be missing something, but it looks like the compiler is doing byte writes here, isn't that what  you wanted?  I assume that the types of these variables are the byte sized enums?



 
Nasty... the compiler was trying to do byte-wide updates ! Needless to say. the -fshort-enums option is now off.
 
One last thing...
When trying to move data from DMA buffers defined in _eds_ space, to working memory, the memcpy() failed without throwing any warnings; it is not eds-aware and the compiler does not realise these are different memory spaces.
I dug around in the libpic30 code and found a _memcpy_eds function which I managed to get working for the purpose. This is not documented anywhere that I can see, but useful nonetheless.



I'm sure it should be documented, sorry if it is not.  I will look into it.  The compiler will also automatically call this for structure copies, so you can properly copy an __eds__ struct to RAM.


 
Regards,
Calum
 
 
 
 



ssparrow
New Member
Re:DSPIC33E and Fast Math 2011/12/19 02:33:33
Hi Calum,
 
Once again thanks for responding.
 
In regards to the Byte-Wide memory operation... you are correct.. that was what I was expecting it to do, but the end result was not what I expected. When updating the variable at address 0x3a43, the variable at address 0x3a42 was being updated as well.
 
I am beginning to wonder if my processor has some strange silicon problem, or RealIce is the issue as today, it suddenly exhibited another type of weird behaviour.
 
I had a piece of code that was working fine 1 minute, then behaving strangely the next.
I was lowering a port bit, calling the Delay_Ms() function (which in turn calls the __delay32() function) then raising the bit.
The code never came back from the call to delay, but instead jumped off into another peice of code... frustrating to identify the cause; almost as though the return was ignored !!
 
I wondered if it was because the stack was in the eds space... no idea why.
 
Will try to reproduce under controlled conditions.
 
Regards,
Steve
 
 
ssparrow
New Member
Re:DSPIC33E and Fast Math 2012/01/25 22:08:27
Hi Calum,
 
I have tried the latest 3.31 compiler and am using MPLAB 8.83, but problems still persist, which I have worked around.
 
To overcome the 'PSVPAG' error when linking fast math libraries , I had to add PSVPAG=0x32 (not 0x34) to the linker script. If I set it to 0x34, the code crashes somewhere in the library.
To get around problems with unreachable code during the link stage, I re-ordered the linker script to put the *(.text); line in. The dynamic allocator has to take a back seat for now.
  .text :
  {
        *(.init);
        *(.user_init);
        KEEP (*(.handle));
        KEEP (*(.isr*));
        *(.text);
        *(.libc) *(.libm) *(.libdsp);  /* keep together in this order */
        *(.lib*);
  } >program
I am still unable to get software breakpoints working and for some reason, only 2 hardware breakpoints are permitted DSP33EP512MU810 device which makes debugging rather tedious (when catching traps and trying to debug other code).
I will lodge another ticket regarding the software breakpoints as eveything else is now working and the tis issue is easily reproduced.
 
I hope that in a future release of the fast math library, you can fix the PSVPAG issue in the sinf function.
I also hope that the Software Breakpoints can be resolved for these devices in the near future
 
Best regards and Happy Chinese New Year (from Hong Kong)
Steve
 
cawilkie
Administrator
Re:DSPIC33E and Fast Math 2012/01/26 07:44:47
Steve,

   Unfortunately 'coming release' did not mean v3.31; that release was already set when you first brought this issue up and I was unable to sneak it in.  I have just fixed it for the next release; if it is causing you pain I can provide you with the (untested - but the change was safe) library.  Just let me know.

  If you could send an example of the breakpoint issue, that would be best.  Please report this via support.microchip.com, if you have not already.  If you have please let me know the ticket number.

Regards
Calum

Happy New Year; year of the dragon I believe?
ssparrow
New Member
Re:DSPIC33E and Fast Math 2012/01/27 04:49:49
Hi Calum,
 
Thanks for the response.. and Happy Year of the dragon..!
 
My apologies on the PSVPAG issue.. I assumed (wrongly) that it was in the 3.31 release, which was the next one I downloaded wink
As for the PSVPAG problem in the sinf() function, I got around it for now using the Linker Script change and the code seems to work fine.
 
I realise it may be too much to ask, but would it be possible for the memcpy() function to be _EDS_ aware (and maybe others)?
No error is reported during compilation if the source and-or destination are in _EDS_ space, but of course the copy fails.
As mentioned bwfore, I invoke the undocumented _memcpy_eds() function, which was "maybe" intended for use by the memcpy() function.
I am in the process of lodging a ticket for the Software Breakpoint issue.. I can reproduce it every time and it is quite annoying... seems to clobber the code and breaks in places you don't ask it to. Never had this issue with the dspic33FJ256GP710 devices that we used in the last version and also, the breakpoint setting was much faster on those chips. it seems to take seconds to set them on the EP device (then they work once and fail subsequently).
 
Best,
Steve