SOLVED: B524 pin configuration confusion

[friedl_1977]

SOLVED!!! : Before using the BSoM evaluation board, make sure to check the jumper configuration! Without doing that, the pins marked as (e.g. D6)

Digital only GPIO, and PWM

might not work as intended. In my case, I was not able to pull them HIGH.

• -------------------------------- *

Hi -

Hoping someone can shed some light, I am losing my mind

I am connecting an ePaper display to a custom PCB. After spending two days debugging the custom PCB, I decided to use a new B524 on a SoM Evaluation board. My initial Pinout used on the custom PCB, that does not work on the SoM eval board either, is below:

#define RST_PIN          D6
#define DC_PIN           D5
#define CS_PIN           SS
#define BUSY_PIN         D7

I then started swopping pins and found the following to work:

#define RST_PIN          D4 
#define DC_PIN           D2 
#define CS_PIN           SS 
#define BUSY_PIN         D7

I then started changing thew pins one by one and it seems the culprits are D5 and D6 connected to RST and DC pins on the screen respectively.

From what I can see in the display Wikipage, the RST, DC and BUSY should be connected to GPIO pins and then declare in the code which I do, but D5 and D6 simply does not work.

Is there a particular reason why e.g. D5 and D6 will not work but swopping them for D4 and D2 solves the problem?

D7 also PWM pin, does not pose a problem?

Many Thanks,
Friedl

[rickkas7]

I can't think of any restrictions on D5 and D6 on the b5som (or bsom).

D5 could be affected if you use FEATURE_ETHERNET_DETECTION on the Boron, but it's on different pins on the B SoM.

The D5 and D6 pins aren't used for other ports like alternate SPI or alternate serial.

D7 can be used as PWM. Since there's no blue D7 LED it should be fine.

[friedl_1977]

Hi @rickkas7 -

EDIT: ------------------------>

Isolated the issue to D6... I will replace the B5Som in the morning, maybe there is a problem with D6 on the hardware side?

Below are couple of results from further testing. The RST pin on the display seems to be the one being pedantic about which GPIO pin it connects to.

/* DEBUG  */

//#define RST_PIN          D22  // fail
//#define RST_PIN          D6  // fail
//#define RST_PIN          D1  // fail

//#define RST_PIN          D2  // ok
//#define RST_PIN          D3  // ok
#define RST_PIN          D4  // ok

#define DC_PIN           D5  // ok
#define CS_PIN           SS  // ok
#define BUSY_PIN         D7  // ok

EDIT: ------------------------<

From what I can see on the datasheets I could not see a reason why this would not work either, hence the post Was really hoping I was missing something obvious...

So just to clarify... If I use:

#define RST_PIN          D6
#define DC_PIN           D5

and wire correspondingly, the ePaper display does not work. If I change it to:

#define RST_PIN          D4 
#define DC_PIN           D2

and wire accordingly, the ePaper display does work. Aside from this, everything else is the same and to eliminate other components or code interfering, I commended everything else out so I only have the ePaper code running.

Regards, Friedl.

[friedl_1977]

@rickkas7

Waveshare support is asking me whether there are any internal pulldown resistors attached to D6? I have done more tests.... it seems the only Digital pins RST_PIN does not work on are D1, D6 and D22 (I might have missed some, not sure whether I tested them all). Below is a list of pins it does work on...

//#define RST_PIN          D9  // ok
//#define RST_PIN          D10  // ok
//#define RST_PIN          D2  // ok
//#define RST_PIN          D3  // ok
//#define RST_PIN          D4  // ok

This behaviour is unique to the RST_PIN. This is demonstrated int the following test.

Working Test

#define BUSY_PIN         D6  // ok
#define RST_PIN          D7  // ok

Failing Test:

#define BUSY_PIN         D7  // ok
#define RST_PIN          D6  // FAIL

From the library the code pertaining to the RST_PIN seems quite straight forward, so not sure what the problem is.

Epd::Epd() {
    reset_pin = RST_PIN;
    dc_pin = DC_PIN;
    cs_pin = CS_PIN;
    busy_pin = BUSY_PIN;
    width = EPD_WIDTH;
    height = EPD_HEIGHT;
    EPD_3IN52_Flag = 0;
};

void Epd::Reset(void) {
    DigitalWrite(reset_pin, HIGH);
    DelayMs(20);    
    DigitalWrite(reset_pin, LOW);                //module reset    
    DelayMs(2);
    DigitalWrite(reset_pin, HIGH);
    DelayMs(20);    
}

Short of remaking the boards I am out of ideas...

Regards,
Friedl.

[rickkas7]

If you flash firmware that only toggles pin D6 slowly and monitor it with a DMM, logic analyzer, or oscilloscope, does it change? Also, do you have pinMode(D6, OUTPUT) somewhere in the code? That is required.

The B523/B524 use a different nRF52840 pin for D6 than the Boron/B402/B404/B404X so it's possible that there could be a difference, but it seems unlikely because pin P1.04 doesn't appear to have any special requirements.

I verified the B52x schematic and M.2 SoM pin 70 is connected to nRF52840 pin P1.04 (U24). This corresponds to SoM pin PWM2 or D6, and this appears to match the b5som pinmap.

I don't have a B52x SoM, but I did test a B404 SoM in the eval board and D6 toggled normally, This isn't a perfect test because the B4xx and B5xx SoM use a different nRF52 pin, but it does show that pin D6 (PWM2) on the eval board does work.

#include "Particle.h"

SYSTEM_MODE(AUTOMATIC);

SYSTEM_THREAD(ENABLED);

SerialLogHandler logHandler(LOG_LEVEL_INFO);

void setup()
{
    pinMode(D6, OUTPUT);
}

void loop()
{
    static bool pinState = false;
    digitalWrite(D6, pinState);
    pinState = !pinState;
    delay(2000);
}

[friedl_1977]

Hi @rickkas7 -

I was meaning to reply sooner but I was out all day and just got back.

I managed to resolve the 'issue' around D6 pin, though not sure why or whether this is intended. There is jumper in one of the two banks of jumpers that seems to cause this behaviour. If I remove the jumper, D6 functions normally. If I bridge the jumper out, D6 goes (and stays) low.

Both Eval boards I have came with all the jumpers bridged out, my mistake in thinking this would be good for 'normal' operation.

Thank you for your efforts!

Regards, Friedl.