Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Address SPI Communication Problem on ATMega2560 #38

Merged
merged 1 commit into from
Nov 21, 2019
Merged

Address SPI Communication Problem on ATMega2560 #38

merged 1 commit into from
Nov 21, 2019

Conversation

phillipjohnston
Copy link

@phillipjohnston phillipjohnston commented Nov 21, 2019

When using the Arduino Mega platform with the W5500 shield, there is contention between the LED signal and the SCK signal. On the Mega, the LED is mapped to digital pin 13. On the Uno, 13 is the SCK signal, but on the Mega these signals are routed to different headers altogether.

The shield still works in sketches because the SPI signals are also routed to the ISCP header, which is connected to the shield.

The logic in the bootloader is that if the SCK pin and LED pin definitions don't match, the LED pin will be initialized and will blink in the bootloader's main polling loop. On the Mega 2560, the SCK pin definition and LED pin definition do not match, meaning this logic was included.

Because of the routing of the signals, LED pin (Digital 13) and SCK are actually shorted together, so blinking the LED is causing contention on the SCK line.

For now, LED blinking is disabled on the ATMega2560. With this change, we can successfully upload binaries to the device over Ethernet.

Fixes #37

When using the Arduino Mega platform with the W5500 shield, there is contention between the LED signal and the SCK signal. On the Mega, the LED is mapped to digital pin 13. On the Uno, 13 is the SCK signal, but on the Mega these signals are routed to different headers altogether.

The shield still works in sketches because the SPI signals are also routed to the ISCP header, which is connected to the shield.

The logic in the bootloader is that if the SCK pin and LED pin definitions don't match, the LED pin will be initialized and will blink in the bootloader's main polling loop. On the Mega 2560, the SCK pin definition and LED pin definition _do not match_, meaning this logic was included.

Because of the routing of the signals, LED pin (Digital 13) and SCK are actually shorted together, so blinking the LED is causing contention on the SCK line.

For now, LED blinking is disabled on the ATMega2560. With this change, we can successfully upload binaries to the device over Ethernet.
@loathingKernel loathingKernel merged commit 1f64f9e into loathingKernel:master Nov 21, 2019
@hagaigold
Copy link

@phillipjohnston why do you think there is contention between the LED and the SCK on ATMega2560?
the SCK is pin 52 (PINB1) while the LED is pin 13 (PINB7).

I actually have a setup with W5500 shield who work with a blinking LED.

The problem you experience is actually in the W5500.
W5500 shield can be used with different boards, e.g. uno or mega.
for the mega the W5500 should be configure differently by "Not Mount" D11, D12 & D13.

switch the LED off will just solve the bootloader contention, if your sketch will use pin 11/12/13 you will have again the same problem.

http://wizwiki.net/wiki/doku.php?id=osh:w5500_ethernet_shield:start

image
image

@phillipjohnston
Copy link
Author

Hi @hagaigold,

You answered the question with your answer. I did not perform (or notice) the necessary rework to eliminate the contention.

@phillipjohnston
Copy link
Author

phillipjohnston commented Jun 29, 2020 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Infinite loop in sockInit
3 participants