RPI Zero hang/crash on Raspbian Stretch Lite 4.14.34 when calling bcm2835_gpio_ren()

[Brody Mahoney]

I have been troubleshooting and debugging some C code for an RFM95 module on my RPI Zero and Zero W. The code uses the bcm2835 gpio lib. I isolated the issue to the bcm2835_gpio_ren() function. When this is called the system completely hangs and becomes unresponsive. The only solution is to cut power and reboot.

I am running the latest version, 1.56. For the following information, I tested on an RPI Zero V1.3 running Raspbian Stretch Lite 4.14.34. Except for SSH and an USB WIFI dongle, no other interfacing options were enabled. I ran apt-get update and upgrade, then installed the bcm2835 lib as instructed in the documentation. No problems.

Here is the final C program where I removed all of the extra calls from another example program (irq_test.c):

#include <bcm2835.h>

int main(void)

{

  if (!bcm2835_init())

    return 1;

  bcm2835_gpio_ren(26);

  bcm2835_close();

  return 0;

}

I compiled it with:

gcc -g irq_test.c -o irq_test -lbcm2835

Here are the gdb results:

gdb: 

Reading symbols from ./irq_test...done.

(gdb) b 4

Breakpoint 1 at 0x1078c: file irq_test.c, line 4.

(gdb) run

Starting program: /home/pi/irq_test

Breakpoint 1, main () at irq_test.c:4

4         if (!bcm2835_init())

(gdb) n

6         bcm2835_gpio_ren(26);

(gdb) s

bcm2835_gpio_ren (pin=26 '\032') at bcm2835.c:351

351         volatile uint32_t* paddr = bcm2835_gpio + BCM2835_GPREN0/4 + pin/32;

(gdb) s

353         uint32_t value = 1 << shift;

(gdb) s

351         volatile uint32_t* paddr = bcm2835_gpio + BCM2835_GPREN0/4 + pin/32;

(gdb) s

353         uint32_t value = 1 << shift;

(gdb) s

354         bcm2835_peri_set_bits(paddr, value, value);

(gdb) s

bcm2835_peri_set_bits (paddr=0xb4e7904c, value=67108864, mask=67108864) at bcm2835.c:238

238     {

(gdb) s

239         uint32_t v = bcm2835_peri_read(paddr);

(gdb) s

bcm2835_peri_read (paddr=paddr@entry=0xb4e7904c) at bcm2835.c:170

170         if (debug)

(gdb) s

177            __sync_synchronize();

(gdb) s

178            ret = *paddr;

(gdb) s

179            __sync_synchronize();

(gdb) s

180            return ret;

(gdb) s

bcm2835_peri_set_bits (paddr=0xb4e7904c, value=<optimized out>, mask=67108864) at bcm2835.c:241

241         bcm2835_peri_write(paddr, v);

(gdb) s

242     }

(gdb) s

241         bcm2835_peri_write(paddr, v);

(gdb) s

bcm2835_peri_write (paddr=0xb4e7904c, value=67108864) at bcm2835.c:208

208         if (debug)

(gdb) s

214             __sync_synchronize();

(gdb) s

215             *paddr = value;

(gdb) s

However, the system only hangs when certain pins are specified. It took quite awhile, but here is a list of the working and non-working pins. Note that when I say working, the C program simply executes without hanging.:

Works:

RPI_V2_GPIO_P1_11

RPI_V2_GPIO_P1_12

RPI_V2_GPIO_P1_13

RPI_V2_GPIO_P1_15

RPI_V2_GPIO_P1_19

RPI_V2_GPIO_P1_21

RPI_V2_GPIO_P1_22

RPI_V2_GPIO_P1_23

RPI_V2_GPIO_P1_32

RPI_V2_GPIO_P1_33

RPI_V2_GPIO_P1_35

RPI_V2_GPIO_P1_38

RPI_V2_GPIO_P1_40

RPI Hangs:

RPI_V2_GPIO_P1_03

RPI_V2_GPIO_P1_05

RPI_V2_GPIO_P1_07

RPI_V2_GPIO_P1_08

RPI_V2_GPIO_P1_10

RPI_V2_GPIO_P1_16

RPI_V2_GPIO_P1_18

RPI_V2_GPIO_P1_24

RPI_V2_GPIO_P1_26

RPI_V2_GPIO_P1_29

RPI_V2_GPIO_P1_31

RPI_V2_GPIO_P1_36

RPI_V2_GPIO_P1_37 

Perhaps not coincidental, 13 pins work while 13 hang the system.

Also, I was testing kernel version updates with Raspbian Jessie Lite and I noticed the system hangs when I upgraded to 4.14.18+ but it works on 4.9.80+, although I do get a kernel message about "Disabling IRQ #73" before it works. That is another issue for a different post though.

Thank you for your time and help.

 

[Mike McCauley]

Thanks.
In the case where the system hangs, is it after one particular instruction
that it hangs? Or should I infer that (in the case where the system hangs) it
hangs when you step the program past line 215? ie that it hangs when executing
__sync_synchronize(); the second time?


Cheers.

> *Works:*
> *RPI_V2_GPIO_P1_11*
> *RPI_V2_GPIO_P1_12*
> *RPI_V2_GPIO_P1_13*
> *RPI_V2_GPIO_P1_15*
> *RPI_V2_GPIO_P1_19*
> *RPI_V2_GPIO_P1_21*
> *RPI_V2_GPIO_P1_22*
> *RPI_V2_GPIO_P1_23*
> *RPI_V2_GPIO_P1_32*
> *RPI_V2_GPIO_P1_33*
> *RPI_V2_GPIO_P1_35*
> *RPI_V2_GPIO_P1_38*
> *RPI_V2_GPIO_P1_40*
>
> *RPI Hangs:*
> *RPI_V2_GPIO_P1_03*
> *RPI_V2_GPIO_P1_05*
> *RPI_V2_GPIO_P1_07*
> *RPI_V2_GPIO_P1_08*
> *RPI_V2_GPIO_P1_10*
> *RPI_V2_GPIO_P1_16*
> *RPI_V2_GPIO_P1_18*
> *RPI_V2_GPIO_P1_24*
> *RPI_V2_GPIO_P1_26*
> *RPI_V2_GPIO_P1_29*
> *RPI_V2_GPIO_P1_31*
> *RPI_V2_GPIO_P1_36*
> *RPI_V2_GPIO_P1_37 *

>
> Perhaps not coincidental, 13 pins work while 13 hang the system.
>
> Also, I was testing kernel version updates with Raspbian Jessie Lite and I
> noticed the system hangs when I upgraded to 4.14.18+ but it works on
> 4.9.80+, although I do get a kernel message about "Disabling IRQ #73"
> before it works. That is another issue for a different post though.
>
> Thank you for your time and help.

--
Mike McCauley VK4AMM mi...@airspayce.com
Airspayce Pty Ltd 9 Bulbul Place Currumbin Waters QLD 4223 Australia
http://www.airspayce.com 5R3MRFM2+X6
Phone +61 7 5598-7474

[Brody Mahoney]

Hi Mike,

Yes it hangs when I step past line 215 every time, on the second __sync_synchronize();

Thanks

[Mike McCauley]

Hmmm,

I wonder if this issue is releated to the version of C compiler on the
affected machine? I read of historical issues with __sync_synchronize.

Cheers,

[Brody Mahoney]

To be honest, I spend most of my time with hardware, and when I code it is on something like an MSP430. Actually, the first time I have ever seen __sync_synchronize() was about 18 hours ago, and I googled it about ... 14 hours ago (according to the time-stamps of the replies above).

With that being said, I am really curious why __sync_synchronize() hangs with one half of the gpios, but not the other half. I just tried to look over the GPIO alternate functions and the underlying BCM pin numbers, and I can't see any obvious patterns between the two.

Maybe I am doing something incorrectly because I am wondering why this hasn't been reported elsewhere. I have searched all over, and haven't found any similar information.

Thanks

[tccio...@gmail.com]

From my experience trying to port BCM2835 C code to C++.

Most public libraries are build to be "universal" - Swiss army knife style. Some are not original code.

Some were build  for RPi1 and do not say so.

I am saying this because I run into multiple #define(s) and into "now usual" issue with NOT identifying when header pins #   or GPIO pins # are being used.

Having made a mistake to (test)  "set" ALL 50 plus  GPIO 50 plus pins  = manipulating wrong pin can lead to hair loss.

 

 

 

[Arjan van Vught]

Op 16 jun. 2018, om 20:12 heeft tccio...@gmail.com het volgende geschreven:

Having made a mistake to (test)  "set" ALL 50 plus  GPIO 50 plus pins  = manipulating wrong pin can lead to hair loss. 

On the Raspberry PI external GPIO header, the GPIO’s < 32 are used. Other GPIO’s are used for example, the EMMC device. Hence working with GPIO’s > 32 should not be done in Linux. 

- Arjan 

[Brody Mahoney]

Hi Mike,

I had a chance to do some more testing and found some interesting results:

On Stretch Lite, the default gcc version is 6.3.0. I installed version 4.9 and 4.4, uninstalled bcm2835, recompiled with each earlier version with no change in behavior. Note: to uninstall I ran sudo make uninstall, and then I modified root and src Makefiles, after running ./configure, to use particular compilers. 

Interestingly, however, I came full circle to another issue, which may in fact be directly related to this issue. I had mentioned above that I was using Raspbian Jessie Lite to use the Radiohead RFM95 port by Charles. In Stretch, the system would hang when running rf95_client. Although everything seemed to function correctly in Jessie, I would always get a kernel message on the first received message: 

kernel:[  xxx.xxxxxx] Disabling IRQ #73

Then everything would work okay afterwards, until I reboot the system. Then I would get the message once again. Earlier I had isolated this kernel message to when I called bcm2835_gpio_ren().

More interestingly, I tested the same pins that would hang the RPi in Stretch 4.14.34, as listed above, but this time after downgrading Stretch to kernel  4.9.80. The result was the kernel message about IRQ #73 disabled. What's more, the pins that would work in Stretch 4.14.34 did not produce a kernel message on first run. 

Here is the gdb dialog when bcm2835_gpio_ren() is called with a pin the causes the kernel message:

(gdb) step

bcm2835_peri_write (paddr=0xb4e7904c, value=4) at bcm2835.c:207

207     {

(gdb) step

208         if (debug)

(gdb) step

207     {

(gdb) step

208         if (debug)

(gdb) step

214             __sync_synchronize();

(gdb) step

215             *paddr = value;

(gdb) step

Message from syslogd@nodeC at Jun 18 06:22:02 ...

 kernel:[  605.788098] Disabling IRQ #73

216             __sync_synchronize();

(gdb) step

218     }

(gdb)

Not surprisingly, the message happens on __sync_synchronize();

So long story short, it appears that the pins that hang the RPi in kernel 4.14.x of Raspian Lite, cause a kernel message about IRQ #73 being disabled on kernel 4.9.80. And both the RPi hang and kernel message happen when the second __sync_synchronize() is called in bcm2835_peri_write().

Brody

[Richard Murphy]

I have the same issue with my RPi3B+ running 4.14.50-v7+. When I call bcm2835_gpio_hen() my program crashes. I believe this has something to do with IRQs being generated by the GPIO pins because on 4.9 I get a system message but the program works. I read where a new overlay called gpio_no_irq was supposed to be in 4.14.X, but it does not appear in my version. This overlay would disable all GPIO interrupts in the kernel. However, it is unclear to me why just enabling high event detect would cause a crash. No actual interrupt is being generated.

I am working with an RFM96 module, BTW.

On Thursday, June 14, 2018 at 2:53:38 AM UTC-5, Brody Mahoney wrote:

[Brody Mahoney]

Interesting, and on a different processor too. It may be very time consuming, but do you know which gpios ade affected?

--
You received this message because you are subscribed to the Google Groups "bcm2835" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bcm2835+u...@googlegroups.com.
To post to this group, send email to bcm...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bcm2835/88c72e25-1f36-4e2d-8941-c658837526a7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Richard Murphy]

Brody

I have not done a full study of this but in my case it was GPIO 05 (physical pin 29). I may check the other pins that do not have another use on my project.

Richard

To view this discussion on the web visit https://groups.google.com/d/msgid/bcm2835/da7e4e64-ef8b-4415-b138-525f324d313a%40gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

[6err...@gmail.com]

Hi,

i tested bcm2835 with kernel  4.9 and 4.14.
With kernel 4.9.xx all ok but with kernel 4.14.xx after some time crash.
Tested only interface SPI.

I can't locate the problem in bcm2835.c.

[Richard Murphy]

I suspect the issue is in this code:

/* Read with memory barriers from peripheral

 *

 */

uint32_t bcm2835_peri_read(volatile uint32_t* paddr)

{

    uint32_t ret;

    if (debug)

    {

                printf("bcm2835_peri_read  paddr %p\n", (void *) paddr);

                return 0;

    }

    else

    {

       __sync_synchronize();

       ret = *paddr;

       __sync_synchronize();

       return ret;

    }

}

In particular, it may be a gcc bug when invoking __sync_synchronized(). If not that, then paddr might be different under 4.14.X, although I am not sure how this would be.

Richard

--

You received this message because you are subscribed to the Google Groups "bcm2835" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bcm2835+u...@googlegroups.com.
To post to this group, send email to bcm...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/bcm2835/6a0bed0b-212c-466d-8556-28b97ad3a0dc%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

[Mike McCauley]

Hello,

On Monday, 16 July 2018 06:34:04 AEST Richard Murphy wrote:
> I suspect the issue is in this code:
> /* Read with memory barriers from peripheral
> *
> */
> uint32_t bcm2835_peri_read(volatile uint32_t* paddr)
> {
> uint32_t ret;
> if (debug)
> {
> printf("bcm2835_peri_read paddr %p\n", (void *) paddr);
> return 0;
> }
> else
> {
> __sync_synchronize();
> ret = *paddr;
> __sync_synchronize();
> return ret;
> }
> }
>
> In particular, it may be a gcc bug when invoking __sync_synchronized().

That is pissible

> If
> not that, then paddr might be different under 4.14.X,

That is not likely.

> although I am not
> sure how this would be.

Cheers.

>
> Richard
>
> On Sun, Jul 15, 2018 at 2:57 PM <6err...@gmail.com> wrote:
> > Hi,
> >
> > i tested bcm2835 with kernel 4.9 and 4.14.
> > With kernel 4.9.xx all ok but with kernel 4.14.xx after some time crash.
> > Tested only interface SPI.
> >
> > I can't locate the problem in bcm2835.c.
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "bcm2835" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to bcm2835+u...@googlegroups.com.
> > To post to this group, send email to bcm...@googlegroups.com.
> > To view this discussion on the web visit
> > https://groups.google.com/d/msgid/bcm2835/6a0bed0b-212c-466d-8556-28b97ad3
> > a0dc%40googlegroups.com

> > <https://groups.google.com/d/msgid/bcm2835/6a0bed0b-212c-466d-8556-28b97a
> > d3a0dc%40googlegroups.com?utm_medium=email&utm_source=footer> .

> > For more options, visit https://groups.google.com/d/optout.
>
> --

[Arjan van Vught]

Op 16-7-2018 om 0:41 schreef Mike McCauley:

In particular, it may be a gcc bug when invoking __sync_synchronized(). 

That is pissible

The __sync_synchronized is implemented as : mcr 15, 0, r0, cr7, cr10, {5} which is a dmb().

This should only be done on a Raspberry Pi Model 1 (first output). On all other boards it should use the native dmb instruction (second output).

The compiler options for the second output is :  -mfpu=neon-vfpv4 -march=armv7-a -mtune=cortex-a7

I have not tested the library, yet, with these native platform settings. So I cannot tell if it is really a solution.

Greets. Arjan

http://www.raspberrypi-dmx.org/

00000150 <bcm2835_peri_read>:
     150:    e92d4800     push    {fp, lr}
     154:    e28db004     add    fp, sp, #4
     158:    e24dd010     sub    sp, sp, #16
     15c:    e50b0010     str    r0, [fp, #-16]
     160:    e59f3040     ldr    r3, [pc, #64]    ; 1a8 <bcm2835_peri_read+0x58>
     164:    e5d33000     ldrb    r3, [r3]
     168:    e3530000     cmp    r3, #0
     16c:    0a000004     beq    184 <bcm2835_peri_read+0x34>
     170:    e59f0034     ldr    r0, [pc, #52]    ; 1ac <bcm2835_peri_read+0x5c>
     174:    e51b1010     ldr    r1, [fp, #-16]
     178:    ebfffffe     bl    0 <printf>
     17c:    e3a03000     mov    r3, #0
     180:    ea000005     b    19c <bcm2835_peri_read+0x4c>
     184:    ee070fba     mcr    15, 0, r0, cr7, cr10, {5}
     188:    e51b3010     ldr    r3, [fp, #-16]
     18c:    e5933000     ldr    r3, [r3]
     190:    e50b3008     str    r3, [fp, #-8]
     194:    ee070fba     mcr    15, 0, r0, cr7, cr10, {5}
     198:    e51b3008     ldr    r3, [fp, #-8]
     19c:    e1a00003     mov    r0, r3
     1a0:    e24bd004     sub    sp, fp, #4
     1a4:    e8bd8800     pop    {fp, pc}

00000150 <bcm2835_peri_read>:
     150:    e92d4800     push    {fp, lr}
     154:    e28db004     add    fp, sp, #4
     158:    e24dd010     sub    sp, sp, #16
     15c:    e50b0010     str    r0, [fp, #-16]
     160:    e3003000     movw    r3, #0
     164:    e3403000     movt    r3, #0
     168:    e5d33000     ldrb    r3, [r3]
     16c:    e3530000     cmp    r3, #0
     170:    0a000005     beq    18c <bcm2835_peri_read+0x3c>
     174:    e3000000     movw    r0, #0
     178:    e3400000     movt    r0, #0
     17c:    e51b1010     ldr    r1, [fp, #-16]
     180:    ebfffffe     bl    0 <printf>
     184:    e3a03000     mov    r3, #0
     188:    ea000005     b    1a4 <bcm2835_peri_read+0x54>
     18c:    f57ff05f     dmb    sy
     190:    e51b3010     ldr    r3, [fp, #-16]
     194:    e5933000     ldr    r3, [r3]
     198:    e50b3008     str    r3, [fp, #-8]
     19c:    f57ff05f     dmb    sy
     1a0:    e51b3008     ldr    r3, [fp, #-8]
     1a4:    e1a00003     mov    r0, r3
     1a8:    e24bd004     sub    sp, fp, #4
     1ac:    e8bd8800     pop    {fp, pc}

[Gerry Lenz]

Hi Arjan,

i tested, but it's the same. After few seconds, the Raspberry crashed.

In src/Makefile i change

CFLAGS = -g -O2

to

CFLAGS = -g -O2 -mfpu=neon-vfpv4 -march=armv7-a -mtune=cortex-a7

regards

Gerry

--

You received this message because you are subscribed to the Google Groups "bcm2835" group.

To unsubscribe from this group and stop receiving emails from it, send an email to bcm2835+unsubscribe@googlegroups.com.

To post to this group, send email to bcm...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/bcm2835/31aed14d-b937-d87d-9b2d-8ac629172559%40gmail.com.

[Brody Mahoney]

Arjan,

I was sifting through the bcm2835 code recently and noticed these lines in bcm2835.h (latest version):

/* RPi 2 is ARM v7, and has DMB instruction for memory barriers.

   Older RPis are ARM v6 and don't, so a coprocessor instruction must be used instead.

   However, not all versions of gcc in all distros support the dmb assembler instruction even on conmpatible processors.

   This test is so any ARMv7 or higher processors with suitable GCC will use DMB.

*/

#if __ARM_ARCH >= 7

#define BCM2835_HAVE_DMB

#endif

It seems like this may be already implemented, although I haven't investigated further.

If that statement does implement the proper command, I commented out the if, and just forced the #define BCM2835_HAVE_DMB. Still the problem persists.

[Brody Mahoney]

Mike,

In hindsight I may have made an error when I answered this question. It was my very first time using gdb, and I think I answered inaccurately. What I meant to say was that it hangs when I execute line 215 not step past it. It seems to be when I step the "*paddr = value;" instruction that the crash occurs. 

I realized this when I was debugging last night and I noticed a similar hang. When using one of my so-called "working pins" from the list above (P1_33) for the IRQ Pin on modified Radiohead code, I experienced a system hang as well. The hang did not occur on the gpio_ren() instruction, but later on during SPI transfer to the RFM95 device:

During this part in the SPI Driver:

RH_RF95::setModeTx (this=0x270c8 <rf95>) at ../../../RH_RF95.cpp:403

403         if (_mode != RHModeTx)

(gdb) s

405             spiWrite(RH_RF95_REG_01_OP_MODE, RH_RF95_MODE_TX);

(gdb) n

406             spiWrite(RH_RF95_REG_40_DIO_MAPPING1, 0x40); // Interrupt on TxDone

(gdb) n   <---Hangs here when next stepping line 406

Running it again but stepping into spiWrite:

RHSPIDriver::spiWrite (this=0x270c8 <rf95>, reg=64 '@', val=64 '@') at ../../../RHSPIDriver.cpp:45

45          uint8_t status = 0;

(gdb) n

46          RPI_CE0_CE1_FIX;

(gdb) n

48          digitalWrite(_slaveSelectPin, LOW);

(gdb) n

49          status = _spi.transfer(reg | RH_SPI_WRITE_MASK); // Send the address with the write mask on

(gdb) n

50          _spi.transfer(val); // New value follows

(gdb) n  <----It hangs here when next stepping line 50

Running once again and stepping into _spi.transfer(val), we end up in bcm2835.c. After a few steps, the hang occurs

bcm2835_peri_write_nb (value=64, paddr=0xb4e89004) at bcm2835.c:223

223         if (debug)

(gdb) s

230             *paddr = value;

(gdb) s   <-----It hangs here when I step instruction 230

Oddly, this instruction gets called repeatedly, but seems to hang when writing 0x40? Not sure.

Anyways, this hang on "*paddr = value;" last night made me review my previous post, which is when I realized I messed up my initial answer. 

On Thursday, June 14, 2018 at 1:29:52 AM UTC-7, Mike McCauley wrote:

[Mike McCauley]

Hi,

Looks to me like your code successfully called
spiWrite(RH_RF95_REG_01_OP_MODE, RH_RF95_MODE_TX);
but the hang or crash occurs when calling
spiWrite(RH_RF95_REG_40_DIO_MAPPING1, 0x40); // Interrupt

and the hang/crash occurs when the line
*paddr = value;
is executed.

But
*paddr = value;
has been executed successfully at least once before this.

Now, RH_RF95 requires interrupts to operate correctly. How do you have the
interrupt set up? Is it possible that when
spiWrite(RH_RF95_REG_40_DIO_MAPPING1, 0x40)
is called, an interrupt occurs, triggering some other part of your code that
stomps on the stack?

Cheers.

[Brody Mahoney]

Yes you are probably correct. It seemed odd that those lines executed before and then suddenly caused a crash. It may very well be that the intertupt is simply not being handled correctly in my code. I will research that.

My previous point about it hanging on the *paddr=value; for the "not working pins" is still what I meant to say though. Hopefully that helps.

Thanks for your help

[ad...@rice.edu]

Has any further progress been made in resolving this issue?

[ad...@rice.edu]

For anyone still experiencing this issue I found that reverting to the 12-01-2017 image of Raspbian (with linux kernel 4.9) solved the problem.

[Brody Mahoney]

Did you notice a kernel message about "Disabling IRQ..." when you called this in 4.9? That is what I experienced, although everything seemed to function just fine.

--
You received this message because you are subscribed to the Google Groups "bcm2835" group.

To unsubscribe from this group and stop receiving emails from it, send an email to bcm2835+u...@googlegroups.com.

To post to this group, send email to bcm...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/bcm2835/a856355d-08f0-4606-b57c-2ae1153cea38%40googlegroups.com.

[Alexander Kaplan]

I did notice the message but only once. I made sure to minimize the potential crashes by enabling the rising edge detect right before I needed it and disabilibg it with _gpio_cl_ren() as soon as I was done. 

To view this discussion on the web visit https://groups.google.com/d/msgid/bcm2835/c6d8fc34-cec7-41cb-a4de-36f600e4ad79%40gmail.com.

[Jason Harper]

For a workaround, try adding this line to your /boot/config.txt:

dtoverlay=gpio-no-irq

This allowed me to run the rf95_client example (from hallard's RadioHead fork) without "hanging" the system (or more accurately, hanging wifi/usb/etc - some userspace was still running)

For an explanation of the cause of the problem in 4.14, why it didn't appear to be happening in 4.9, and some of the downsides of enabling the gpio-no-irq overlay, see: https://github.com/raspberrypi/linux/issues/2550

Hope this helps someone

Jason

[Mike McCauley]

Thanks,

Ive added a note to the documentation for the next release.

Cheers.

> >>> You received this message because you are subscribed to the Google
> >>> Groups "bcm2835" group.
> >>> To unsubscribe from this group and stop receiving emails from it, send

> >>> an email to bcm2835+u...@googlegroups.com <javascript:>.

> >>> To post to this group, send email to bcm...@googlegroups.com

> >>> <javascript:>.

> >>> To view this discussion on the web visit
> >>> https://groups.google.com/d/msgid/bcm2835/a856355d-08f0-4606-b57c-2ae115
> >>> 3cea38%40googlegroups.com

> >>> <https://groups.google.com/d/msgid/bcm2835/a856355d-08f0-4606-b57c-2ae1
> >>> 153cea38%40googlegroups.com?utm_medium=email&utm_source=footer>.

> >>>
> >>> For more options, visit https://groups.google.com/d/optout.


--

[you are here]

FYI: I'm running your latest build on Linux pihost 4.14.79-v7+ #1159 SMP Sun Nov 4 17:50:20 GMT 2018 armv7l GNU/Linux

That's a pi 3B, and having the same problem. Crashes calling ...ren(). Doesn't (so far) with workaround.

Paul

[Dennis Obukhov]

Hello there.

I had a similar issue when was connecting RFM95 modem and Raspberry Pi 1 Model B. My Raspberry froze every time the modem received a message . I figured out that the cause was HIGH signal on IRQ pin. Finally I disconnected the modem and run IRQ test:

#include <bcm2835.h>
#include <stdio.h>

#define RF_IRQ_PIN RPI_GPIO_P1_07 // IRQ on GPIO04 so P1 connector pin #07

int main(int argc, char **argv)
{

  // If you call this, it will not actually access the GPIO
  if (!bcm2835_init())
    return 1;

  // Set RPI pin to be an input
  bcm2835_gpio_fsel(RF_IRQ_PIN, BCM2835_GPIO_FSEL_INPT);

  //  with a puldown
  bcm2835_gpio_set_pud(RF_IRQ_PIN, BCM2835_GPIO_PUD_DOWN);

  // And a rising edge detect enable
  bcm2835_gpio_ren(RF_IRQ_PIN);
 
  while (1) {
    // we got it ?
    if (bcm2835_gpio_eds(RF_IRQ_PIN)) {
      // Now clear the eds flag by setting it to 1
      bcm2835_gpio_set_eds(RF_IRQ_PIN);
      printf("Rising event detect for pin GPIO%d\n", RF_IRQ_PIN);
    }
    // wait a bit
    bcm2835_delay(5);  
  }

  bcm2835_close();
  return 0;
}
   

Sending HIGH signal (3.3v) to pin #7 caused the RPi to freeze ( Env:  bcm2835-1.58 installed on Linux raspberrypi 4.14.79+ #1159 Sun Nov 4 17:28:08 GMT 2018 armv6l GNU/Linux

Eventually I bumped into this group and tried adding "dtoverlay=gpio-no-irq" to /boot/config.txt, which helped. 
Thank you.

понедельник, 3 декабря 2018 г., 0:54:16 UTC+2 пользователь Mike McCauley написал: