Several issues with Clicker 2 dsPIC33 board

[esimetti]

Greetings.

I have bought 20x Clicker 2 for dsPIC33, together with the same number of Buggy, and a few clicker sensor boards, since I'm teaching Embedded Systems here at the University of Genova, Italy.
However, after the first class, I'm already facing several issues that I never had with my previous boards (dsPIC dem 2 from microchip).
I'm using the mikrobootloader, so the clicker board is connected only through USB to the PC. I'm using MPLAB X to generate the hex file.

So, the first issue is the oscillator setup. I was reading some old posts, and I'm wondering: can we use the #pragma directives to change the setup of the board? Or we are bound to some initial choice made by the bootloader? And if so, which setup is that? By reverse engineering, it seems that with no further configuration, the device runs with FOSC = 140 MHz. Is that correct? Can we use the registers to change the oscillator settings?

Besides the issue of the oscillator, I now have a problem with 3 boards.
For one of them, the "CHG" LED (red) lights up as soon as I attach the USB, even if the battery is not connected. If the battery is connected to the buggy, and the USB cable is detached, the CHG led stays off. After letting it run for a while, the LED is now quickly blinking.

For the other two boards, I have problems with both running the firmware and the bootloader.
Sometimes, I press the reset button, and nothing happens. The device does not enter the bootloader and cannot be seen from the Mikrobootloader.
Sometimes, if I press the reset for a prolonged time, it enters the bootloader. However, this behavior cannot be reproduced effectively.
In the meantime, the firmware simply doesn't run and the dsPIC is sort of "freezed".
Turning the on/off switch doesn't make the bootloader or the pre-loaded firmware start. This behavior does not depend on the fact that the clicker 2 board is connected to the buggy or not.

Finally, some other times after programming a board, or just reconnecting the USB cable, I get "Reset device to reenter bootloader mode." multiple times.

I hope you can help us because we've spent a good chunk of money to get all these setups for the students.

Best,
Enrico

[IvanJeremic]

Hi,

"I was reading some old posts, and I'm wondering: can we use the #pragma directives to change the setup of the board?"

No, you won't be able to use #pragma directives to change the setup of the board.


"Or we are bound to some initial choice made by the bootloader? And if so, which setup is that?"

Unfortunately you are bound to the Bootloader settings in this case, you can see the config bits and the attached BOOTLOADER project below:
FGS : $F80004 : 0x0003
FOSCSEL : $F80006 : 0x0083
FOSC : $F80008 : 0x00A5
FWDT : $F8000A : 0x007F
FPOR : $F8000C : 0x003F
FICD : $F8000E : 0x00D7
FAS : $F80010 : 0x0003

bootloader.rar

(438.19 KiB) Downloaded 22 times

As for the HW issues that your clicker boards are showing, as i understand it only 3 boards are showing issues, or did i misunderstand and all 20 are having issues?

Regards,

Ivan.

[esimetti]

Dear Ivan,

thanks for the confirmation.
Even using different settings for PLLFBD and CLKDIV in the main would have no effect?

As regards the HW issues, yes it is related to 3 of them. We have used around 14 boards so far since we have around 13 groups.
However, it is a bit worrying since the issue happened in the very first 2 hours of use.
Do you have any insight?

[IvanJeremic]

Hi,

Yes, when it comes to PIC, dsPIC and PIC32 you are bound to the BOOTLOADERs settings.

As for the 3 faulty ones i suggest you return them.

If you bought it directly from us, then make a ticket using the link below, in the ticket send your order number, your decision on what to do with the boards (refund, replacement) and if you want a replacement type in the address where you want the replacements to be sent to.
https://helpdesk.mikroe.com/

If you bought them from a distributor, contact them, you can use this conversation as a reference.

Regards,

Ivan.

[esimetti]

Dear Ivan,

thanks for sharing the bootloader.
I just wanted to point out that there is an incoherent comment in the bootloader main:

Code: Select all

  // Setting output frequency to 140MHz
  // Using primary oscillator (8MHz) with PLL
  PLLFBD = 70;             // PLL multiplier M=70
  CLKDIV = 0x0000;         // PLL prescaler N1=2, PLL postscaler N2=2

While the comment mentions a clock of 140MHz, the settings configure the micro to work at 144MHz.

As it concerns the boards, I noticed the following. The voltage on the RST pin was not 3.3V, as it should be when not reset, but was lower and sometimes it was decaying over time. We've resoldered all the header pins, and it appears that two of them are now properly working again. Can the soldering of the headers create such an issue?

For one of the boards, the RST pin measures around 380mV, effectively keeping the device reset. In fact, the device cannot be seen from the mikrobootloader.
The other board with the CHG led also still misbehaves.
For these two boards we will proceed as you suggested, contacting the distributor.

[IvanJeremic]

Hi,

"While the comment mentions a clock of 140MHz, the settings configure the micro to work at 144MHz."
Thank you for your input, i have forwarded this to the developers so they can correct the comment.

"The voltage on the RST pin was not 3.3V"
It could be that the headers got damaged during the shipping so re soldering them fixed the issue.

Regards,

Ivan.