Hello Lubin,

First of all As you have probably guessed by now I am currently working with the 33FJ256MC710 and they recently (April 18) came out with an errata plagued with problems in the ADC, UART, SPI, PWM, OC and DMA. Too late for me to change the chip :evil: .



Now,almost all of those peripherals (except for DMA) are supported by your blockset and I really understand that you can not write code for the blocksets in a way that meets all of the errata out there. Many of the workarounds require you to not meet certain conditions in the registers, so I was wondering if it could be possible for you to add a space in the blocks configuration window where we could see what are the actual values being set for the involved registers and leave to us (the users) the responsibility to configure the device in such a way that does not fall into the errata.



For instance, for the SPI, at the bottom in gray I would see someting like



SPI1CON1 = 0xABCD

SPI1CON2 = 0xAAAA

SPI1STAT = 0xABCD

etc...



Also there is one thing that I want to ask if you could do in your end for this errata.

4. Module: DMA Module: Interaction with

EXCH Instruction

The EXCH instruction does not execute correctly

when either of the two operands is numerically

equal to the address of any of the DMAC SFRs for

this revision of silicon.

Work around

If writing source code in assembly, the

recommended fix is to replace:

EXCH Wsource, Wdestination 
with: 
PUSH Wdestination 
MOV Wsource, Wdestination 
POP Wsource 

If using the MPLAB C30 C compiler, specify the

compiler option,

 -merrata=exch 

(Project>BuildOptions>Projects>MPLAB

C30>Use Alternate Settings)

In other words, could you add that flag to the compiler options?



In conclusions, two requests: Could you let us see the values of the involved registers and add the above mentioned flag to the compiler options?



Thanks!



Mariano

Hi Mariano,



About the first proposition:

Citation : malife

see what are the actual values being set for the involved registers

This is difficult since for most peripheral, Theses register's values are not computed at the matlab workspace level but directly in the C code generated.

Btw, isn’t it possible to avoid the "buggy special condition" by using configuration parameters itself?



For the second point, You just have to add "-merrata=exch" at the end of : menu Simlation ==> Configuration Parameters ==> Real Time Workshop -> dsPIC Options -> Optimisation Parameters : OPTIM_GCCLine ==> -mcpu=33fJ256MC710 -O3 -fschedule-insns -fschedule-insns2 -merrata=exch



The, You should remove the directory generated by Real Time Workshop so as to have all the matlab library compiled with this new parameter.



Let me know if you can't find a workaround for the first problem mentioned...

Hello Lubin,

Thanks for your quick response. I will include that in my compiler. As for the conditions, I guess I can look at the generated source via simulink's HTML report. Just one question then: All the initialization of the periphereals (unless I explcitly say it changes, like the SPI option) happens in the same function?



Thanks!



Mariano

Hello Mariano,



All basic initialization task are done in the c file wih the same name as your model. Let say <ModelName>.c

At the bottom of this file is the initialization function :

void <ModelName>_initialize(boolean_T firstTime)>



I hope this will help.



Lubin