I don't see how I can effectively help you when you're running a modified version of the firmware that I am not familiar with and are unable to demonstrate the the problem originates from the standard codebase (not to say that it doesn't). You need to debug your code and figure out what's happening. If you get to a conclusion that some of the existing code is wrong, I would love to look into it. If you have specific question about the code or about how to debug I would love to help.
On Tue, Mar 31, 2015 at 9:28 AM, Vincent Nadon <[email protected]> wrote: > *UPDATE*: I have found the problem related to the non responsive calls of > twi.readWrite() with my custom firmware (V3.x), this was due to some > modifications we did in the i2c.c file commenting all calls of rx_queue. > After uncommenting these lines, the Andrdoid App received the read > acknowledge (Result...). > > I still wasn't able to make V5.x *stock *firmware work on my custom > platform. As you say I would probably need to try it on a stock IOIO > hardware board, but at this time for me it is too complicated (buying a > IOIO, trying it, then trying to debug my custom board again) and it would > get me further from the problem that I already partly solved. > > *Now, I have two problems*: > > 1. After about 24 twi.readWrite() calls, my PIC restarts by itself so > I can only do 24 reads whether it is 1 every 100ms or 1 every 1second. In > my case I would like to do 22x 10 readings, 1 every 100ms. I had previously > decreased DEFINE_STATIC_BYTE_QUEUE to 128 instead of 8192 for the rx to > have enough memory space for proper functionnality of my DSPs. I tried to > increase it to 2048, but then my audio signals didn't sound right in my DSP > and also it didn't solve the problem that after 24 reads the PIC restarts. > To me this seems to be some kind of buffer problem, when it gets full it > crashes. I guess there could be a way to reset this buffer every few calls, > if we find this faulty buffer?? > 2. I cannot read the response value. I see in my PIC logging that the > command to read passes and the correct value is in the buffer in the PIC, > but it doesn't get in the Android App... > > > Le vendredi 27 mars 2015 11:22:59 UTC+1, Vincent Nadon a écrit : >> >> I'm only talking about the Hardware firmware now. I can't even try with >> my Android App since my hardware doesn't even boot and therefore doesn't >> establish the bluetooth or USB connection. As I said I am using the IOIO >> V5.x as plain as I can. I will try again without changing anything at all, >> but chances are there might be something that I need to modify that I don't >> see. >> >> As you say it is hard to find the problem since I have custom hardware >> and therefore need to modify the Firmware a bit. >> >> >> Le vendredi 27 mars 2015 08:43:31 UTC+1, Ytai a écrit : >>> >>> There are too many things that can go wrong in your setup: custom IOIO, >>> custom forward with changes that are very likely to break stuff and a fair >>> amount of complexity in your app. >>> I recommend that you start by eliminating some possible causes (e.g. >>> test your app on a stock IOIO with stock firmware or run a rigorous test on >>> your custom hardware/firmware, such as the IOIO torture test. >>> Otherwise you'd be wasting our time. >>> On Mar 26, 2015 9:30 AM, "Vincent Nadon" <[email protected]> wrote: >>> >>>> >>>> - So I tried the V5.X firmware, as plain vanilla as I could. I have >>>> put some call for LEDs to light up during boot process and I connected >>>> an >>>> Arduino USB2Serial to monitor the logging. >>>> >>>> As it is, no LEDs light up and I don't see anything in the logging, >>>> no "***** Hello from app-layer! *******", nothing... Even my bluetooth >>>> dongle doesn't seem to light up anymore. >>>> >>>> >>>> >>>> I did configure everything to suit my hardware (PIC24FJ256DA206) and >>>> then also changed the pins for my UART according to what I had working in >>>> my previous firmware, and changed few pins for LEDs. I also configured the >>>> ENABLE_LOGGING in the pic30-gcc preprocessor macros. >>>> >>>> >>>> >>>> >>>> libusb, libconn, libbtstack, libadb, Bootloader and AppLayerV1 all >>>> build without errors. >>>> >>>> >>>> >>>> - I have also another question, in my previous firmware version I >>>> had to set Memory_Model to Large Data, Large code and small scalar. I >>>> also >>>> had to modify QUEUE_SIZE in protocol.c to 128 (instead of 8192) to fit >>>> the >>>> code to program my DSPs in the pic memory. Would you have a better >>>> suggestion to provide the memory space for DSP code? (I use the pic to >>>> program my DSPs at bootup) >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "ioio-users" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to [email protected]. >>>> To post to this group, send email to [email protected]. >>>> Visit this group at http://groups.google.com/group/ioio-users. >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> -- > You received this message because you are subscribed to the Google Groups > "ioio-users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/ioio-users. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "ioio-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/ioio-users. For more options, visit https://groups.google.com/d/optout.
