It’s already week 3. Time flies on internship. Its really not boring either. I sometimes spend +8 hours in the office but I’m never thinking “Oh man when can I leave?” Instead its “shit I’ve been here for 10 hours I should probably leave”.

This week’s work was a continuation of last weeks’. First I wanted to make my tests better by not using “no operation for loops” as delays. It would take a different amount of time on every board even when they were all programmed to the same clock. I realized I needed to use the on board clock to create an accurate delay. And then my university education flashed before my eyes… and I began writing… into google search on how to create a delay function for a PIC32.

#define READ_CORE_TIMER()     _CP0_GET_COUNT() \\to header file

void Delay_us(uint32_t microseconds)
{
uint32_t time;

time += (SYS_CLK_FREQ / 2 / 1000000) * microseconds;
while ((int32_t)(time - READ_CORE_TIMER()) > 0){};
}

I also verified the functionality of the prototypes as HTTP  Web-servers. I’d really like to blame Hofstadter’s Law on the time it took me for this one, but instead I’m just going to advice you to get 8 hours of sleep to save you from silly mistakes you’d never notice.

There is a very specific issue with all prototypes. When the boards ping the server its fine. Then if you disconnect the ethernet and reconnect within ~1min 30sec , the boards will resume pinging fine. If you disconnect the ethernet for more than ~1min 30sec then reconnect it, pinging the server doesn’t work anymore, but you can still have the server ping the boards which still works  ~_~

I tried to troubleshoot it by forcing a timed hardware reset of the LAN chip such that it would occur 1min 50 sec after I’ve disconnected the ethernet. But the issue persisted. On the old boards there was no effect. On the new boards the LAN chip loses functionality and it can no longer establish a link.

(╯°□°）╯︵ ┻━┻

Categories: Experiential