用PicKit3调试dsPIC33FJ32MC304有问题吗？

如果您提供在编程过程中显示的消息（无论成功与否）可能与PICTIT3有关。基本上，DSPIC33 FJ32 MC304应该是可编程的和可调试的与PICkit -不确定关于MPLAB 8。（我使用MPLAX X -除了偶尔的用户错误以外没有其他问题。）



      以下为原文

    Might help if you provide the messages displayed during programming (whether successful or not) with the PICkit3.
 
Basically the dsPIC33FJ32MC304 should be programmable and debuggable with the PICkit - not sure about MPLAB 8.x. (I'm using MPLAB X - no problems other than the occasional user's error.)

什么版本的MPLAB？



      以下为原文

    What version of MPLab?

我在我原来的文章中说：MPLAB IDE 8.90。



      以下为原文

   


I said in my original post: MPLAB IDE 8.90.
 

我会很快的。关于类似问题的其他帖子表明，MCLR的上拉不应超过10K。我们正在将4.7K更改为10K，不久将再次尝试。谢谢您确认。



      以下为原文

   
 
I will soon.
 
Other posts about similar issues suggest that the pull-up on MCLR should not be stronger than 10k. We are changing our 4.7k to a 10k and will try again shortly. 
 



Thank you for confirming that.
 

4K7可能是个问题。同样的情况，如果你的电线束在PICTIT3和板之间太长。（请不要问多长时间太长-取决于电线/电缆，电线布线等。把电线切成两半有时能解决问题。



      以下为原文

    The 4k7 might be an issue. The same applies if your wire harness between PICkit3 and the board is too long.
(Please don't ask how long is too long - depends on the wires/cables, wire routing and more. Cutting the wires in half sometimes solves issues.)

我应该提到，我们一直使用MPLAB 8.90，只要我能记得。我们只使用几个DSPIC33和PIC32 MX部分已经完全支持这个版本的MPLAB（像今天的这个DSIC33 FJ32 MC304部分）。为了仔细检查，我查看了MPLAB 8.90的发行说明，他们声明了对PICTIT3调试和PICTIT3编程的支持（绿色/YES）。我没有看到任何注释中的任何东西都会引起任何红旗，我们之所以选择这个设备，是因为它在以前的产品中使用，这意味着图表和大部分软件代码都已经知道了。我相信今天的问题不是IDE造成的。



      以下为原文

   


I should mention that we have been using MPLAB 8.90 for as long as I can remember. We are only using several dsPIC33 and PIC32MX parts that have been fully supported by this version of MPLAB (like this dsPIC33FJ32MC304 part today). To double-check, I looked at the release notes for MPLAB 8.90 and they do state that dsPIC33FJ32MC304 is supported (Green/Yes) for PicKit3 Debug and PicKit3 Programming. I don't see anything in the notes to raise any red flags -- and the reason we chose this device is because it was used in a prior product which means the schematics and most of the software code are already known. I believe today's problem is not caused by the IDE.
 

我们正在做一些改变：-我很快就会回来报告结果。



      以下为原文

   


We are making some changes :-)
 
I'll be back soon to report on the outcome.
 

如果你已经有了一个DSPIC33 FJ32 MC304的板，明智的做法是检查当前的“问题板”是否有与编程接口（路由、已拔出的拉杆，但也有缓冲电容器）相关的变化。



      以下为原文

    If you already had a board with the dsPIC33FJ32MC304, it would be wise to check whether the current "problem board" has changes that would be related to the programming interface (routing, the pullup already identified, but also e.g. buffer capacitors).
Seeing forward to your report...

我们改变了MCLR上拉到10K欧姆。我们注意到USB电缆从计算机到PACKIT3的一个问题。震动皮卡3使它与计算机连接/断开。改变USB电缆解决了这个问题，我们改变了从PICTIT3到MCU的连接。这是一个两端连接良好的6英寸扁平电缆。一旦进入电路板，信号就从调试连接器到MCU引脚250毫秒。这是一个调试生成配置。试图调试程序打印这些消息：



      以下为原文

   
 
We changed the MCLR pull-up to 10k ohm.
 
We noticed a problem with the USB cable from the computer to the PicKit3. Shaking the PicKit3 caused it to connect/disconnect from the computer. Changing the USB cable resolved this.
 
We changed the connection from the PicKit3 to the MCU. This is a 6-inch flat cable with good connections on both ends. Once in the board, the signals travel 250 mil from the debug connector to the MCU pins.
 
This is a Debug build configuration. Attempting to program for debugging printed these messages:
 

PICkit 3 detected
Connecting to PICkit 3...
Running self test...
Self test completed
Firmware Suite Version...... 01.28.56
Firmware type......................dsPIC33F/24F/24H
PICkit 3 Connected.
PK3Err0045: You must connect to a target device to use PICkit 3.
Resetting...
Target Detected
Device ID Revision = 00003004
Erasing...
Erase device complete
Programming...
PK3Err0037: Timed out waiting for response from PICkit 3
Programming failed

 

看来你仍然有一个问题的USB。或者你的机器上的总计算负荷太高。



      以下为原文

   
 
Seems you still have an issue with the USB. OR the overall computing load on your machine is too high.

VCAP/VDDCORE CAP。有联系的？



      以下为原文

    vcap/vddcore cap. connected?

这样地：



      以下为原文

   


Like this:
 
 
   Attached Image(s)

我们注意到了另外一件事。假设我们从调试切换到编程。我们可以加载一个程序，它运行（通过切换GPIO引脚来产生方波验证）。试图重新编程（改变，编译，程序）始终产生：编程…编程失败，直到我们第一次擦除闪存设备。我记得，在过去，能够编程和重新编程一整天，而不必擦除闪存设备。



      以下为原文

   
 
We noticed another thing. Suppose we switch from Debug to just Programming. We can load a program and it runs (verified by toggling a GPIO pin to produce a square wave). Attempting to program again (make a change, compile, program) consistently produces:
 
Programming...
Programming failed
 
Until we first Erase Flash Device.
 
I remember, in the past, being able to program and reprogram all day long without having to Erase Flash Device.

你的记忆力有点不完善：这样的系统存在（称为“仿真器”），但是需要比单个闪存微控制器更多的硬件（至少没有任何颜色的PICS）。



      以下为原文

   
 
Your memory is somewhat imperfect:
Such systems existed (called "emulators"), but required much more hardware than a single Flash microcontroller (at least no PICs of any color).

你的记忆力有点不完善：这种系统存在（称为“仿真器”），但需要比单个闪存微控制器更多的硬件（至少没有任何颜色的PICS）。在任何情况下，一旦我们解决了各种连接器/电缆问题，我们能够使用PACKIT3只用于编程，并能够重复擦除闪存设备，其次是程序。我们仍然无法使用PICTIT3进行调试。我不知道我们的设置是什么阻止了这一点。没有复杂的路由（MCPGC/PGD引脚正好在编程插针旁边，没有通路或其他障碍物）。我们有三块木板。我们改变了4.7K欧姆电阻到10K欧姆在一个板上，它没有什么区别。我可以始终如一地编程4.7K和10K欧姆板（但不调试）。配置保险丝和时钟设置代码自从我第一次发布以来就有了轻微的变化。配置保险丝：特别是我们现在使用的是ffSoScL（fnScOracle Frc＆EioOSOOFF），用FLC启动，没有PLL。将PLL转换为FRC+PLL如下：这将调用编译器内蕴添加到OSCCon上。（奇怪的观察：我复制了最初发布的时钟设置代码，就像以前的产品一样，在没有OSCCon写入的情况下工作。它是用FRC+PLL启动的，默认PLL设置，然后改变PLL设置？我认为必须首先切换到FRC，然后与PLL混乱，然后切换回FRC+PLL。奇怪的是）之前我还玩过POR计时器，使用了从128到几毫秒的不同值。我从另一个论坛帖子中收集到它应该是没有的，所以我把它返回到那个设置。我真的不知道接下来该检查什么。很好，我们至少可以编程愚蠢的事情，但有一些新的代码，我需要断点和验证寄存器看起来好，等等，顺便说一下，什么电压应该出现在MCLR调试期间？早些时候示波器在这条线上显示了一些10V的信号。这似乎正确吗？可能是愚蠢的问题：需要启用JTAG接口吗？也就是说，目前我们已经有了（ICSU-PGD1和JTAGENEXOFF）。是否应该更改为OFICD（ICSU-PGD1和JTAGEN）？



      以下为原文

   
 
Your memory is somewhat imperfect:
Such systems existed (called "emulators"), but required much more hardware than a single Flash microcontroller (at least no PICs of any color).




Fair enough. In any event, once we solved various connector/cable issues, we are able to use PicKit3 for Programming only and are able to repeatably Erase Flash Device followed by Program. We are still unable to use PicKit3 for Debugging. I cannot figure out what it is about our setup that prevents that. There is no complicated routing (the MCU PGC/PGD pins are literally right next to the programming connector pins with no vias or other obstacles in the way). We have three boards. We changed the 4.7k ohm resistor to 10k ohm on one of the boards and it made no difference. I can consistently Program both the 4.7k and the 10k ohm boards (but not Debug).
 
The configuration fuses and clock setup code have changed slightly since I first posted.
 
Configuration fuses:
 
 // Register FBS (0xf80000):
// - Boot Segment may be written
// - No Boot program Flash segment
_FBS(BWRP_WRPROTECT_OFF & BSS_NO_BOOT_CODE)


// Register FGS (0xf80004):
// - User program memory is not write-protected
// - User program memory is not code-protected
_FGS(GWRP_OFF & GCP_OFF)


// Register FOSCSEL (0xf80006):
// - FNOSC_FRC Internal Fast RC (FRC)
// - IESO_OFF Start-up device with user-selected oscillator source
_FOSCSEL(FNOSC_FRC & IESO_OFF)


// Register FOSC (0xf80008):
// - Primary oscillator disabled (using internal FRC)
// - OSC2 pin is general purpose I/O
// - Peripheral Pin Select: Allow multiple reconfigurations
// - Clock switching is enabled, Fail-Safe Clock Monitor is disabled
_FOSC(POSCMD_NONE & OSCIOFNC_ON & IOL1WAY_OFF & FCKSM_CSECMD)


// Register FWDT (0xf8000a):
// - Watchdog Timer enabled/disabled by user software
_FWDT(FWDTEN_OFF)


// Register FPOR (0xf8000c):
// - POR Timer Disabled (no delay at power up)
// - I2C mapped to SDA1/SCL1 pins
// - PWM module low side output pins have active-high output polarity
// - PWM module high side output pins have active-high output polarity
// - PWM module pins controlled by PORT register at device Reset
_FPOR(FPWRT_PWR1 & ALTI2C_OFF & LPOL_ON & HPOL_ON & PWMPIN_ON)


// Register FICD (0xf8000e):
// - Communicate on PGC1/EMUC1 and PGD1/EMUD1
// - JTAG is Disabled
_FICD(ICS_PGD1 & JTAGEN_OFF)

 
In particular we are now using _FOSCSEL(FNOSC_FRC & IESO_OFF) to startup with FRC without PLL.
 
Later we set up the PLL and switch to FRC + PLL as follows:
 
  // Use internal 7.37 MHz FRC with PLL to achieve:
  // 40 MHz CPU clock (Fcy)
  // 40 MHz Peripheral clock (Fp)
  CLKDIVbits.FRCDIV = 0; // Internal Fast RC oscillator divide by 1 (7.37 MHz)
  CLKDIVbits.PLLPRE = 1; // N1 PLL prescaler = 3 (divide input clock of 7.37 MHz by 3 to give 2.463 MHz)
  CLKDIVbits.PLLPOST = 0; // N2 PLL postscaler = 2 (divide 160.12 MHz by 2 to give 80.05 MHz Fosc = 40 MHz Fcy and 40 MHz Fp)
  PLLFBDbits.PLLDIV = 63; // M PLL multiplier = 65 (multiply 2.463 MHz by 65 to give 160.12 MHz)

  // Writing to OSCCON requires using compiler intrinsics
  __builtin_write_OSCCONH(0x01); // NOSC = 1, Fast RC (FRC) oscillator with divide-by-N and PLL (FRCDIVN + PLL)
  __builtin_write_OSCCONL(OSCCON | 0x1); // OSWEN: Oscillator Switch Enable bit

  // Wait for new clock to stabilize
  while (OSCCONbits.OSWEN) {
  }

 
This adds the calls to the compiler intrinsics to write to OSCCON.
 
(Strange observation: I copied the originally posted clock setup code as from a prior product, where it worked without the writes to OSCCON. Was it starting up with FRC+PLL with some default PLL settings and then changing the PLL settings? I thought one must first switch to FRC, then mess with the PLL, then switch back to FRC+PLL. Weird.)
 
Also earlier I played with the POR timer, using various values from none to 128 ms. From another forum post I gathered that it should be none so I returned it to that setting.
 
I'm really not sure what to check next. It's great that we can at least program the silly thing, but there is some new code that I need to breakpoint and verify that registers look okay, etc.
 
Incidentally, what voltages are supposed to be present on MCLR during Debug? Earlier the oscilloscope showed some 10V signal on that line. Does that seem correct?
 
Possibly dumb question: Does the JTAG interface need to be enabled? I.e., currently we have _FICD(ICS_PGD1 & JTAGEN_OFF). Should that be changed to _FICD(ICS_PGD1 & JTAGEN_ON)?
 

至少在MPLAB X中存在另一组保险丝设置，IMHO覆盖在十六进制文件装入链接后编译的设置。如果存在这样的集合，则可以启用另一个调试接口-或者如果调试被禁用（另一个选项位）。…那你就不足为奇了。…



      以下为原文

    At least in MPLAB X there exists another set of fuse settings that IMHO overwrite the settings compiled when the HEX file is loaded post linking. If such a set exists hat enables another debug interface - - - or if debugging is disabled (another option bit) . . . then you sholdn't wonder . . .

此消息意味着PK3的“VDD”PIN上的连接有故障。



      以下为原文

   
This message implies that the connection on the PK3's "VDD" pin is faulty.

我已经检查过了。-在MPLAB 8.90中，这是这个窗口（见附件），正如你在图像中看到的，“代码中设置的配置位”被选中，窗口变灰了。如果取消选中复选标记，窗口变为白色，可以使用配置位进行播放。



      以下为原文

   


I checked for that already. :-)
 
In MPLAB 8.90 that is this window (see attached), and as you can see in the image "Configuration bits set in code" is selected and the window is grayed out. If you de-select that check mark, the window turns white and you can play with configuration bits.
 
   Attached Image(s)

在你的第一个帖子里，JTAGEN已经关闭了！我怀疑你可以在它关闭的时候进行调试：



      以下为原文

    In your very first post, JTAGEN is set to OFF!
I doubt that you can expect to debug while it is off :)