I made a few additional experiments with the EEPROM server demo.
in main.c: PLLFBD=41; // 40 MIPS in ENC28J60.c: ENC_SPICON1 = 0b00011; // 8:1 / 1:1
--> no connection at all. Also no connection when using for example ENC_SPICON1 = 0b11010; // 2:1 / 4:1
However, both settings work, when switching to PLLFBD=20; // 20 MIPS
So what could cause this?
a) Maybe the FRC oscillator has a too high jitter at high frequencies which messes up SPI communication to the ENC28J60?
b) Maybe the dsPIC33 is fast enough at the 40 MIPS setting so that it can trigger one of the SPI related silicon bugs mentioned in the errata http://ww1.microchip.com/downloads/en/D ... 80443D.pdf I don't know what to make of this, but erratum 3, 4, and 19 are all SPI related. Maybe someone with more knowledge could read these few errata paragraphs?
Some comment in ENC28J60.c says: "4:1 primary prescale, 1:1 secondary prescale (10MHz @ 40MIPS, Doesn't work. CLKRDY is incorrectly reported as being clear. Problem caused by dsPIC33/PIC24H ES silicon bug.)" But the fix they used seems to be using 1:1 primary prescale, 5:1 secondary prescale) -- strange.
When the board is in this state, the LD1 LED connected to the PIC is still blinking, so the while(1) loop is still running, and the ACT LED connected to the ENC28J60 still shows traffic on the network caused by other devices.
I found it convenient to be able to power the Web Platform using my iPhone USB charger and a normal USB cable. It is also convenient when presenting the board to friends and powering it using their computer. Therefore I soldered a pluggable (via two DIL socket pins) connection from the USB power to the 3.3 volts regulator (picture attached). I measured the consumed current which is about 200 mA, so when powering no additional hardware with the Web Platform it should be ok for most USB ports.
In the past 24 hours I have been testing with the value 0b10011 (0x13) which is 10 MHz @ 40 MIPS, and although stability has improved, the web server still hangs after at most a few hours.
I read about the stability of the #tweet tree, but it was achived by running the dsPIC with only 20 MIPS.
I wonder if stability at 40 MIPS would improve, if a more stable clock source than the internal FRC could be used. I know, SPI has its own clock pin, but just wondering...
Although possible, the likeliness that a bug in the Microchip TCP/IP stack is causing this behavior is quite low.
I checked in the .hex file of the ds33Intro project, but did not commit new versions of the .hex files for the MCstackDemo, MCstack-SDcard-server, and tweet_tree projects.
I posted a comment at the "introduction-to-dspic33-programming" page [1] but am reposting it here in the forum so that it does not get overlooked:
I think using 0b11 in the line _FICD(JTAGEN_OFF & 0b11); is not correct. 0b11 is expanded to the 16 bit value 0b0000000000000011 which sets all other bits in FICD to zero. Better use ICS_PGD1 which is defined as 0xFFFF: _FICD(JTAGEN_OFF & ICS_PGD1)
This is *really an issue* when using a PIC programmer to program the firmware. It took me quite some time to figure out, why most of the examples do not work on the Web Platform when programmed with a programmer, but work fine when transferred using the bootloader. The bootloader seems to not program the config bits, at least not the bits in FICD, which hides the bug introduced when using & 0b11.
MCstackDemo MCstack-SDcard-server, and ds33Intro all contain this bug in either HardwareProfile.h or main.c. It should really be corrected in the SVN (and ideally also in the provides .zip files in the download section) to prevent others from stumbling over this issue.
I could do the work if I get SVN commit permissions assigned.
I got the same behavior as mcdanne82 describes in his initial posting. After a few minutes, the start page of the Microchip demonstration web-content, which shows the buttons and the blinking LED in the browser via AJAX, stops and says it has lost the connection ("Error: Connection to demo board was lost.").
wallabybob is right: The original value for ENC_SPICON1 is 0x0F (8 MHz @ 40 MIPS). I stepped through the respective code lines with the debugger. The ENC28J60 data sheet says that the SPI clock can be as high as 20 MHz. Taking into account Ians comment, that <10 MHz might be too slow, I tried 0b11011 (0x1b) which should be 20 MHz @ 40 MIPS, but this was not working at all. Next, IIRC, I used 0b10111 (0x17) which should be about 13.3 MHz @ 40 MIPS, but results did not improve.
Now I am using 0b10011 (0x13) which is 10 MHz @ 40 MIPS which gives me the most stable behavior. It is now already serving continuously for about an hour. I would be interested in results other people get.
The bootloader on the Web Platform must be running when trying to upload. To achive this, you have to press the reset switch S1 on the Web Platform, and then, within 2.5 seconds, perform the upload using the ds30 Loader application.
I do not have any example code (since I am still waiting to receive my Web Platform ... sigh), but as I understand it from reading the docs you can use the functions declared in C:Microchip SolutionsMicrochipIncludeTCPIP StackXEEPROM.h (and defined in C:Microchip SolutionsMicrochipTCPIP StackSPIEEPROM.c) to access the EEPROM.
With the mpfs utility (which you use to generate the image from the directory containing the web pages) you can specify how many bytes it should reserve for your custom data.