2
\$\begingroup\$

My question is about using FRC as an oscillator source and OSC2 pin as an I/O pin.

In several different manuals on dsPIC30F chips (ex: DS70139G, page 126) it is written:

   LP     Secondary       0 0 0   XXXXX  (Note 1, 2)
   FRC    Internal FRC    0 0 1   XXXXX  (Note 1, 2)
   LPRC   Internal LPRC   0 1 0   XXXXX  (Note 1, 2)

   Note 1: The OSC2 pin is either usable as a general purpose I/O pin or is completely
   unusable, depending on the Primary Oscillator mode selection (FPR<4:0>).

I carefully searched manuals, errata, forums, etc. But I cannot find clarification on how to set the FPR bits in the FOSC register to be able to use OSC2 as an I/O that the Note 1 suggests. Is this possible at all?

Errata on dsPIC30F3012 suggests using FRC with PLL and postscaler to make this pin useable (DS80448D - pages 3, 15). But this errata states that this problem is applicable only to revision B0, that is relatively old. We have chips of revision B1. Was this issue really fixed in B1? If yes, the work around should not bee needed, but in this case how this feature should be used?

Are there any differences in dsPIC30F3010 and dsPIC30F4011 devices regarding this issue?

I use assembler from XC16 v1.11. The sample code is (the part that sets FOSC):

.section    __FOSC.sec, code
            .pword    0xC701;         // FRC with 4x PLL.

Update:

I made experiments on programming undocumented FPR's into the device. As an environment I was using MPLABX and ICD3. It turns out that compiling always goes fine and the .hex file always contains the values that I put into the code. But some part of the tool chain blocks programming the undocumented FPR values into the device. After programming the "Configuration Bits" tabs shows the value C100 (FRC without PLL) and device works like this value is really programmed there.

The behavior described above (blocking programming) happens to majority of the values. The values 0x02, 0x04, 0x06, 0x08, 0x09, 0x0b, 0x0c manage to get through, but device does not seem to work properly.

These experiments have not destroyed the device.

\$\endgroup\$
1
\$\begingroup\$

I haven't used the part in a while, but it should be just a case of setting the configuration bits correctly. You don't say what compiler you are using so I can't give a code example, but your compiler manual should let you know (the commands will probably be at the end of the include file)

Also, you are better off reading the 30F family reference manual (Section 7 is the Oscillator) as it's far more detailed than the datasheet.

If you let us know which compiler and maybe post the code you have already tried it would help give a more specific answer (e.g. a code example)

I notice in the table below the FPR bits are dashed out for the FRC without PLLoption, even though note 1 says the pin function is dependent on these bits (if so, how should they be set?) This seems suspicious, I think I would raise a support ticket with Microchip to see what they have to say on the matter.

dsPIC30F OSC2 pin function

\$\endgroup\$
  • \$\begingroup\$ I updated my post. @Oli, the doc that you are pointing at does not contain anything new/significant on the issue. \$\endgroup\$ – Kirill Kobelev Mar 14 '13 at 4:20
  • \$\begingroup\$ Fair enough, sorry (the FRM was also just in case you were unaware of it, as it's more thorough on the other parts of the chip to). Looking through I can see it shows options for the PLL with the I/O, but doesn't mention the non-PLL case as you allude to. Is it working as an IO with the PLL turned on? I though I had a couple of 3012's to try here, but I can't find them. Hopefully someone else can be of more help. \$\endgroup\$ – Oli Glaser Mar 14 '13 at 4:35
  • \$\begingroup\$ When the PLL is enabled, the pin works as I/O. I tried this. My impression that their Note 1 is plain bogus and the errata stating that something is fixed in rev. B1 is bogus either. \$\endgroup\$ – Kirill Kobelev Mar 14 '13 at 4:39
  • \$\begingroup\$ Ah, okay - so it works with the PLL but not without? I updated my answer, I notice the table seems to lack the required info, or it is bogus as you say. I'd try a support ticket. Let us know what you discover for future viewers if you do ask them. \$\endgroup\$ – Oli Glaser Mar 14 '13 at 4:48
  • \$\begingroup\$ With PLL it works, does not work without PLL. Basically errata suggests the right workaround. Do you know if Microchip answers all questions to everybody? I already posted them a ticket on this. Do you think it makes sense to try all 32 variants of the FPR field to see what will happen? Will that be reliable enough? I will update my post is I will discover something. \$\endgroup\$ – Kirill Kobelev Mar 14 '13 at 4:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.