raspberry pi 2 crashe after runing printipi

[mohamedamineamdouni]

raspberry crashe after run printipi

this is the output

[INFO] Printipi: built for machine: 'rpi::firepickdelta' [INFO] Filesystem root: / [INFO] platforms::rpi::UnwrappedHardwareScheduler::initSrcAndControlBlocks: #dma blocks: 196608, #src blocks: 65536

[Wallacoloo]

That log information puts the error between lines 412-414 here (because the next log statement should occur inside of initDma(), but we aren't seeing it).

Is it just the program crashing? Or is it bringing down the entire system, and you have to reboot the Raspberry Pi? If it's the latter, you likely have some other program that's using the same DMA channel & you could try using a different one here. You can try every integer between 0-15, but 8-15 have reduced performance, and you run a chance of disk corruption if you happen to choose the same channel that the SD card uses so make sure you don't have anything important on there (or do your research to figure out which channels are 'safe' first).

If it's just printipi that's crashing, then make sure you're running it as a privileged user (e.g. sudo printipi). If it still fails, then run it in gdb and grab a stacktrace to get some indication of where the problem is:

$ sudo gdb printipi
(gdb) r
[wait for program to crash]
(gdb) bt
#0  0xf7de8b40 in [...]
#1   0xf7ddcdc8 in [...]
[...]

It's entirely possible that the Pi 2 has its peripherals (like DMA) mapped to different memory addresses, or that newer kernels restrict userland programs from directly accessing those.

Worst case, you can disable DMA entirely by deleting line 71 here:

    PLAT_DEFINES:=$(PLAT_DEFINES) -DPLATFORM_DRIVER_HARDWARESCHEDULER='"platforms/$(PLATFORM)/hardwarescheduler.h"'

but that will result in slower movements with more jitter.

[Wallacoloo]

Digging through the archives, it looks like you aren't the first to have issues using the Pi 2:

https://groups.google.com/forum/#!topic/printipi/V-WXhf2tpDE

So I'd say that chances are pretty good that some portion of the DMA interface has changed between Pi 1 and Pi 2.

[mohamedamineamdouni]

hello Os is it bringing down the entire system it's the problem of the DMA i solve it with

make clean make PLATFORM=generic i read here https://www.raspberrypi.org/forums/viewtopic.php?f=32&t=86339 Avoid DMA channels 0, 1, 2, 3, 6, 7. The GPU uses 1, 3, 6, 7. The frame buffer uses 0 and the SD card uses 2.

[mohamedamineamdouni]

https://github.com/hzeller/rpi-gpio-dma-demo/blob/master/gpio-dma-test.c this can help you to change the code to be used in RPI2

[Wallacoloo]

Thanks for the reference. By the way, make PLATFORM=generic will have the side effect of replacing all gpio writes with dummy operations, so the fans, heater, steppers, etc won't work. The solution I posted above disables only DMA, so it should work better. On Apr 23, 2016 8:47 AM, "mohamedamineamdouni" notifications@github.com wrote:

https://github.com/hzeller/rpi-gpio-dma-demo/blob/master/gpio-dma-test.c this can help you to change the code to be used in RPI2

— You are receiving this because you commented. Reply to this email directly or view it on GitHub https://github.com/Wallacoloo/printipi/issues/91#issuecomment-213767708

[mohamedamineamdouni]

i disable it but it still don't work :/

[mohamedamineamdouni]

this is the out put root@octopi:/home/pi/printipi/build# ./printipi [INFO] Printipi: built for machine: 'rpi::firepickdelta' [INFO] Filesystem root: / [INFO] fpdelta XYZ_STEPS: 166.666667 [INFO] fpdelta XYZ_STEPS: 166.666667

[prtngn]

Hi all. Is there any progress to run printipi on Raspberry PI 2 and 3? I try change DMA, but failed. If i disable DMA, raspberry is hang:

root@print:/media/printipi/printipi# ./build/printipi
[INFO] Printipi: built for machine: 'rpi::firepickdelta'
[INFO] Filesystem root: /
[INFO] fpdelta XYZ_STEPS: 166.666667
[INFO] fpdelta XYZ_STEPS: 166.666667

[Wallacoloo]

Hi Maxim, I haven't tried to use the Pi 2, and since no one has submitted any pull requests for Pi 2 support, I doubt anyone else has been working on this.

If you can find the manual for the new Broadcom processor in the Pi2/3, you might try cross-referencing the peripheral addresses. I wouldn't be surprised if the GPIO bank or the PCM peripherals have new memory addresses. On Jun 29, 2016 8:13 AM, "Maxim" notifications@github.com wrote:

Hi all. Is there any progress to run printipi on Raspberry PI 2 and 3? I try change DMA, but failed. If i disable DMA, raspberry is hang:

root@print:/media/printipi/printipi# ./build/printipi [INFO] Printipi: built for machine: 'rpi::firepickdelta' [INFO] Filesystem root: / [INFO] fpdelta XYZ_STEPS: 166.666667 [INFO] fpdelta XYZ_STEPS: 166.666667

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Wallacoloo/printipi/issues/91#issuecomment-229388194, or mute the thread https://github.com/notifications/unsubscribe/ABJ5fwhy_TWCA4sBrqK5NHhpVxdgV_A2ks5qQoukgaJpZM4IN-03 .

[prtngn]

And this example: https://github.com/Wallacoloo/Raspberry-Pi-DMA-Example/blob/master/dma-example.c working, but this: https://github.com/Wallacoloo/Raspberry-Pi-DMA-Example/blob/master/dma-gpio.c is hung. Datasheet on bcm2836 not exist =)

P.S. I make debug log and program hang on initpwm. P.P.S.

platform::rpi::hardwarescheduler::start_init_pwm
segfault at aaddress 0xA0
Exiting

P.P.P.S. I comment initPwm function and get this result:

fpdelta XYZ_STEPS: 166.666667
fpdelta XYZ_STEPS: 166.666667
Set phtread sched_priority

And hang.

[sarumpaet]

https://github.com/richardghirst/PiBits/commit/96014c804d68677baf4fff25178f9b152c1f31e6 (in ServoBlaster) might be another reference for GPIO changes for the Pi 2.

[Wallacoloo]

FWIW, there's some more info regarding the dma-example linked 2 posts up, which works on Pi 1 but not later versions: https://github.com/Wallacoloo/Raspberry-Pi-DMA-Example/issues/1

It's likely that the bus address of L2 cache has changed between the Pi 1 and other versions, and not just the peripheral addresses.

In the Pi 1, L2 cache is at 0x40000000 and DRAM is at 0xc0000000. You can see in the servoblaster code that it appears to pick 0x40000000 for the Pi 1 and 0xc0000000 for the Pi 2 when choosing which L1-bypass bus address to write to.

I don't know if this means that L2 cache was moved to 0xc0000000 and DRAM is elsewhere in the Pi 2, or if L2-cache is no longer bus-addressable because there wasn't enough address space for it to fit. In any case, I suspect that replacing 0x40000000 with 0xc0000000 in the functions that translate physical addresses to L1-bypassed addresses will work for both Pi versions, and updating the peripheral addresses for Pi v2 will fix things there. I'm not heavily invested in this project though - I'm just leaving these notes for anyone else that wants to give it a shot.