patdb

Using the Scope (and Plot) utility of the IDE we have observed that gathered values of Motor[1].CapturePos always return 0, while the Watch window reports the correct value. Note: the PowerPMAC software reference manual defines Motor[x].CapturePos as boolean with a formal range of 0-1. The Gather.Type is 1542 (i.e. an unsigned 8-bit number with start bit 0). However, by examining the 32bit register using Gather.Udata we found out that the start bit actually should be 24. If we override Gather.Type with the value 50694 (defining an unsigned 8-bit number with start bit 24) then the Scope utility returns the correct values for Motor[1].CapturePos. So it seems that for Motor[x].CapturePos the Gather.Type is not set correctly. This has been observed with: PPMAC Firmware 2.3.2.5 PowerPMAC IDE v3.0.1.0 Could this be a firmware related bug?

We are currently using the “Command()” or “GetResponse()” PMAC API methods (Gp Library Functions in gplib.h) to submit commands from a background C application (which in turn is talking to the outside world) to the PMAC command interpreter . However, those particular methods do not support commands such as "$$$", "$$$***", "save". What is the recommended way to submit these commands via the gplib API?

I issued "Sys.DebugMode=$AAAAAAAA" via gpascii and read Sys.DebugMode to confirm that the value was set correctly before starting the debugger. Regrettably, it did not solve the problem; the symptoms are still the same.

Description: The debugger hangs and communication is lost when trying to debug a background program (such as capp1) that links to libppmac.so on ARMv7. This problem does not occur if the PMAC library is not linked (i.e. plain c or c++ code). Further details: The bug is not caused by the PowerPMAC IDE nor the ARM cross-compiler as it can be reproduced solely using gdb via console on the device. Moreover, the problem is not caused by a certain call to a method as it also happens if the body of capp1’s main method is completely replaced by a simple printf(). It even occurs when the breakpoint is set in line 1 which may indicate that the problem arises during the initialization phase. The breakpoint itself is reached but the system is not responding any more (communication is lost and no longer possible unless rebooted). Upon initialization of gdb a warning is displayed: “warning: Unable to find libthread_db matching inferior’s thread library, thread debugging will not be available.” According to a quick Google search it appears that certain versions of gdb have problems with multithreaded libraries. Could this be the problem? System: Firmware 2.2.0.37, PowerPMAC IDE 3.0.0.2