sandeepmistry / arduino-nRF5

Arduino Core for Nordic Semiconductor nRF5 based boards
Other
902 stars 278 forks source link

SPI won't work on nRF52 SDK + Adafruit SHARP Memory Display (144x168 pixels) #514

Open vtpgit opened 1 year ago

vtpgit commented 1 year ago

Hello:

This seems a rather old project, not sure if anyone is still maintaining it, but it's worth the shot.

I'm using an official nRF52-DK SDK (nRF52832) from Nordic with Sandeep's NRF5 and BLEPeripheral, on Arduino IDE 1.8.18.

I'm also using Sharp Memory Display ( Adafruit SHARP Memory Display (144x168 pixels) ).

I'm trying to drive the display, but no luck. I got two displays, just in case one is faulty, but both are just showing random pattern and no communication. I'm running the built-in example from Adafruit.

The SDK otherwise is perfectly healthy, the BLE works, no problems.

There are my pins:

include

include

define SHARP_SS 10 //P0.22

define SHARP_MOSI 11 //P0.23

define SHARP_SCK 13 //P0.25

// Set the size of the display here, e.g. 144x168! Adafruit_SharpMem display(SHARP_SCK, SHARP_MOSI, SHARP_SS, 144, 168);

Attached is a picture of my setup. I'm using the standard example that came with Adafruit SHARP Memory library.

If anyone has any idea why it doesn't work, I'll very highly appreciate your input. I'm willing to donate/contribute to this project or anyone who helps.

Please let me know what else is needed to debug the issue.

Cheers!

IMG_20231002_163846 1

ereich1217 commented 1 year ago

This is likely caused by using GPIO pins which have restricted drive strength and frequency.

Pins P0.22, P0.23 and P0.25 all have limited drive strength and can only be used at low frequencies. If you change the wiring to unrestricted pins and your code to match then it may work.

Scroll to the bottom of this page in the Nordic documentation and you will see the GPIO usage restrictions:

https://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.nrf52832.ps.v1.1%2Fpin.html&resultof=%22%70%30%2e%30%38%22%20

Good luck.

vtpgit commented 1 year ago

Sandeep's variant file lists those are SPI pins, why would that be, if he knew those pins have such a restriction?

I copied those from his variant:

/*

define PIN_SPI_MISO (12)

define PIN_SPI_MOSI (11)

define PIN_SPI_SCK (13)

static const uint8_t SS = 10 ; static const uint8_t MOSI = PIN_SPI_MOSI ; static const uint8_t MISO = PIN_SPI_MISO ; static const uint8_t SCK = PIN_SPI_SCK ;

Any input is appreciated.

Meanwhile, let me check the link you provided. Thank you!

Cheers!

vtpgit commented 1 year ago

I'm back to report that there was no effect. I tried two combos on the pins farthest away from the antenna:

define SHARP_SS 20 //P0.05

define SHARP_MOSI 25 //P0.06

define SHARP_SCK 27 //P0.08

and

define SHARP_SS 21 //P0.02

define SHARP_MOSI 14 //P0.03

define SHARP_SCK 20 //P0.05

I checked if those are the actual pins by on/off -ing then and checking with an oscilloscope one by one, since the library is abysmally poor at specifying which pin maps to which integer, I had to experimentally find out the mapping, but whatever, I did it.

At that point I give up.

I'm willing to hire someone to dig into this.

Any takers?

I have low confidence this library could really work, as I see others have made it work using the Nordic basic core in PlatformIO and the same Sharp Memory display library, so I'm doing it right code-wise. Also I checked and replaced the wiring in case of a bad wire, no luck.

I would of course appreciate if anyone points me in the right direction. I might be doing something wrong. This at that point seems like a library/board definition issue.

Cheers!

ereich1217 commented 1 year ago

Since you have an oscilloscope have you checked that the signal coming out looks like a valid SPI signal?

If you have a 4-channel scope use that to capture all 4 signals and the SS to trigger to stabilize the capture.

vtpgit commented 1 year ago

Since you have an oscilloscope have you checked that the signal coming out looks like a valid SPI signal?

If you have a 4-channel scope use that to capture all 4 signals and the SS to trigger to stabilize the capture.

I do have an oscilloscope but for that have something better, a logic analyzer. I ran the exact same code, except the pins, on an Arduino MEGA 2560, and it ran flawlessly out of the box, and the memory display worked as it should, no questions, there, so I captured the output, looks just like an SPI output.

The I hooked the NRF52 and the output was garbage, so it's definitely a library problem. At that point I conclude the sandeepmistry library has an issue. Any ideas? Anything I could try to debug and narrow the issue?

Cheers!

ereich1217 commented 1 year ago

Before concluding it is a library problem look at it with an oscilloscope, or if your logic analyzer can record in analog mode look at it that way.

The MEGA 2560 is 5V and the NRF52 is 3.3V. If you do a digitial capture of 3.3V signal that is interpreted as 5V digital logic the signals can look fairly chaotic.

Have you confirmed that your display is capable of communicating at a 3.3V level?

sandeepmistry commented 1 year ago

From your photo in https://github.com/sandeepmistry/arduino-nRF5/issues/514#issue-1923009955, it looks like the 5V is connected to Vin, have you tried using 3.3V (VDD) instead?

vtpgit commented 1 year ago

The MEGA 2560 is 5V and the NRF52 is 3.3V

Yes, the nRF52-DK has 5V, that's really not the problem, it's something completely different. I wish it were that easy.

looks like the 5V is connected to Vin, have you tried using 3.3V (VDD) instead?

Nope that's really not the problem. The logic analyzer clearly shows the SPI is misconfigured.

I spent close to 20 hours but I'm on the right track. I had to re-write some of the SPI h and c, then re-point the pins to the ones away from the antenna, and now I can get correct SPI sent out to the analyzer. Before it was crapping I'm not sure why and not worth my time and effort digging.

Next is to dig into the Adafruit library to find out at what point it calls the SPI and re-write those parts too.

So, it's a messy combo of problems between the SPI for NRF in Sandeep's library combined with the Adafruit's SHARP display library which relies on the underlying SPI library defaults. I would not be surprised if the adafruit bit-bangs the SPI, that would be absolutely hilarious.

I will figure it out however I'm not sure if this is directly transferrable to other's efforts. I totally suck as PRs, so could create a list of things I modified, and create an example but don't forget that would involve changing the adafruit library too, so caveat emptor.

I'm a very determined person, so I'll make it work, no problem. But definitely, the variant file and lack of documentation of which P0.xx maps to which integer on the DK is a major suck. However, I don't look a gifted horse in the mouth, so that's that.

I'll come back to report. Thanks for the suggestions. Sandeep's library is a good piece of work, it just needs some usability makeover. If I can port it to PlatformIO would be best but one step at a time.

Cheers!

image

vtpgit commented 1 year ago

I'm coming back to report, the adafruit library defaults to bit-banging the SPI which creates a whole 'nather bag of problems, apparently this nrf core can't handle some of the adafruit fast pin manipulations. This is funny.

So the problem cascades leading to a comedy of errors. The adafruit library attempts to find hardware SPI, but fails, the nrf core doesn't properly advertise the availability of a hardware spi. adafruit then goes for sw spi and since it's a mosi only data it never checks if the data was properly sent and just keeps banging out while the cs, sck and mosi pins have already gone to the cuckoo clock. bang-on, baby!

I'm not really sure at that point it's worth my time digging any further. the sharp memory display library is so simple i'm going to rewrire it from scratch for nrf52 hw spi using my own changes to sandeep's hardware spi headers, that's only couple hundred lines of code i need to write.

I'm putting a stop on this, if anyone wants to fix sandeep's library to properly handle spi please go ahead, i provided with enough information here.

But definitely, a proper pin mapping documentation is an absolute must.

Cheers!

vtpgit commented 1 year ago

Last report. I made it work, but it involved some light soldering at the end. You can see what I did here:

https://val-balkanski.livejournal.com/3516.html

Cheers!

ereich1217 commented 1 year ago

CONGRATULATIONS! Way to stick with it.

vtpgit commented 1 year ago

Way to stick with it.

LOL I'm like a crocodile, once I bite, it's game over.

Thanks for your help!

Cheers!