Open vtpgit opened 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:
Good luck.
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:
/*
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!
I'm back to report that there was no effect. I tried two combos on the pins farthest away from the antenna:
and
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!
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.
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!
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?
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?
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!
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!
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!
CONGRATULATIONS! Way to stick with it.
Way to stick with it.
LOL I'm like a crocodile, once I bite, it's game over.
Thanks for your help!
Cheers!
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!