Announcement

Collapse
No announcement yet.

uLCD-32PTU resets using file_CallFunction

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    Well isn't the display 'identical' in both tests?

    Hence the only thing that is changing is the 'controller'?

    The propeller should be waiting for the 'ACK', so really the speed shouldn't come into it.

    confusing
    Mark

    Comment


    • #17
      You can decode at least one half of the tx/rx by using the programming device (Cable, PA5, whatever) and using the 'Terminal' program to monitor it
      Mark

      Comment


      • #18
        I thought I would use my scope to look at wave forms and see if I could determine what was being sent. Since a person can get lost looking at a bunch of vertical lines, I modified my code to insert a 100msec delay between transmitted bytes, just to get some seperation on the scope display. In so doing, my function now returns the expected result!

        I don't need the delay after the second byte (0x19), but I need it after all the others or the uLCD crashes.

        The weird thing is, I've created about a hundred functions that successfully send commands to the uLCD-32PTU, and this is the first time I've had to slow down the transmission of data.

        I tried to reduce the length of the delay, but even 50msec crashed the uLCD.

        This has me scratching my head. This raises many more questions.

        Have you ever seem such a problem? Can it be a baud rate issue? I have it set at 19200.

        Comment


        • #19
          Never seen it before, the internal buffer of the LCD can receive at 600kbaud without losing anything.

          Weird, can you try my suggestion for capturing the data above and see what you get?

          What about the power supply, is it 'somehow' marginal?
          Mark

          Comment


          • #20
            I've tried battery power and wall wart. Both function satisfactorily.

            I've deleted the 100msec delay after each transmission that a talked about in post #18.. It's inconsistent with desired results

            I've captured the serial data as requested. Here's what I got for sampleNP.4FN (no pause):

            NOTE: The included lister files are CSV. I had to rename them to satisfy the uploader.

            After baud rate changed and things settle down, at 700.8 ms:
            Mount:
            - - TX - - FF, 03
            - - RX - - 06, 15, 4C
            LoadFunction:
            - - TX - - 00, 08, 73, 61, 6D, 70, 6C, 65, 4E, 50, 2E, 34, 66, 6E, 00
            - - RX - - 06, 94, E9
            WriteString:
            - - TX - - 00, 21, 00, 00, 48, 65, 6C, 6C, 6F, 20, 57, 6F, 72, 6C, 64, 00
            - - RX - - 06, 01, 0E
            CallFunction:
            - - TX - - 00, 19, 94, E9, 00, 03, 00, 05, 00, 05, 01, 0E
            - - RX - - 06, 00, 00
            ReadString:
            - - TX - - 00, 22, 01, 0E
            - - RX - - 06, 00, 0F, 49, 20, 68, 61, 76, 65, 20, 72, 65, 74, 75, 72, 6E, 65, 64
            Unmount:
            - - TX - - FF, 02
            - - RX - - 06
            (Last transmission received at 903.7 ms.)
            samplenp_data.txt

            Everything is in order with this one.

            Here's what I got with sampleP.4FN (with pause(3000) ; )
            At 700.8 ms
            Mount:
            - - TX - - FF, 03
            - - RX - - 06, 15, 4C
            LoadFunction:
            - - TX - - 00, 08, 73, 61, 6D, 70, 6C, 65, 50, 2E, 34, 66, 6E, 00
            - - RX - - 06, 94, E5
            WriteString:
            - - TX - - 00, 21, 00, 00, 48, 65, 6C, 6C, 6F, 20, 57, 6F, 72, 6C, 64, 00
            - - RX - - 06, 01, 0E
            CallFunction:
            - - TX - - 00, 19, 94, E5, 00, 03, sampleP00, 05, 00, 05, 01, 0E
            (Last transmission at 852.5 ms. Nothing sent or received after that time.)
            samplep_data.txt
            Attached Files
            Last edited by TomLewis; 11th February 2018, 04:50 PM. Reason: Edited to point out the txt files are CSV files that have been renamed.

            Comment


            • #21
              I wanted to verify that the pause command in the 4FN file was indeed the issue.
              I created 3 new files, and moved the pause(3000) line to lines 7, 9 and 11 respectively.
              By observing the display, I could verify each file crashed at the pause(3000) command.

              Next I tried a pause in my test file. I paused for 1 second immediately before I called CallFunction and it didn't crash!

              I tried other delay values but the display crashed with any delay less than 1 second.

              Here are the lister files. These are CSV but I had to rename them to satisfy the uploader.

              sample_p_fail.txt
              sample_p_pass.txt

              It appears that if the 4FN file includes a pause(xyz), there needs to be a delay prior to calling CallFunction, and if there is no pause(xyz), no delay is required.

              What do you think?

              Comment


              • #22
                Update:

                file_Run and file_Exec have the same issue and are solved by the same workaround.

                Comment


                • #23
                  The last line of your posted "Here's what I got with sampleP.4FN" says
                  Code:
                  - - TX - - 00, 19, 94, E5, 00, 03, sampleP00, 05, 00, 05, 01, 0E
                  Did you really send that? If I send a representation like that the display restarts.

                  Is it possible the Propeller library is resetting the display thinking there's been some timeout?

                  I wrote a little program to do what you are ding using the Serial library on Windows, here's a log from it
                  Code:
                  09:29:17.348: Start
                  09:29:17.513: Mount Done
                  09:29:17.579: Load Function Done
                  09:29:17.601: String Written
                  09:29:17.601: Calling Function
                  09:29:17.643: Function Returned
                  09:29:17.668: I have returned
                  09:29:17.770: End
                  09:29:22.148: Start
                  09:29:22.315: Mount Done
                  09:29:22.386: Load Function Done
                  09:29:22.410: String Written
                  09:29:22.412: Calling Function
                  09:29:25.458: Function Returned
                  09:29:25.483: I have returned
                  09:29:25.586: End
                  You can see the difference between the pause and the non pause by the difference in the function return times. The SPE was loaded with the baud rate set to 19200

                  The source and the source of the two functions are all in the attachments
                  Attached Files
                  Mark

                  Comment


                  • #24
                    Originally posted by ESPsupport View Post
                    The last line of your posted "Here's what I got with sampleP.4FN" says
                    Code:
                    - - TX - - 00, 19, 94, E5, 00, 03, sampleP00, 05, 00, 05, 01, 0E
                    Did you really send that? If I send a representation like that the display restarts.
                    No, that was a typo on my part. The file 'samplep_data.txt' is the accurate representation of what I sent and received.

                    The propeller only sends a reset at the beginning of the program. See the code file in post 3.

                    Should I be able to run the file 'lodcallfn.exe' in the zip folder? If so, I'm getting a timeout error after the first line.


                    Comment


                    • #25
                      Yes, you should be able to run it, SPE needs to be 'ready' and the speed setting needs to match the SPE speed, and, of course the com port needs to be correct
                      Mark

                      Comment


                      • #26
                        I forgot to change the baud rate to match my display. Now I get the same results as you show in post #23.

                        Let me investigate.

                        Comment


                        • #27
                          Rather than messing with the display's default speed, I ran lodcallfn at 9600. I also tried my test program at 9600 but no change.

                          A ran your test program, lodcallfn, while hooked to the scope and compared the lister log to mine. The first difference I noticed, is that you started by clearing the screen, where I did not.

                          The pointers were different, as may be expected, but otherwise, TX and RX were identical, byte-for-byte, up to where my display reset and yours didn't. The only other difference was that my program ran about 10% faster.

                          I added gfx_Cls to my program but it didn't make any difference.

                          I also scoped the Reset on H1 and H2. The only activity was from the propellers initial reset. Nothing after that.

                          I don't suppose there is any way to create a dump log from the display? I'm thinking the reset has to be software initiated.

                          Comment


                          • #28
                            On further investigation, I decided to replicate exactly what you had in lodcallfn. I eliminated resetting the display and the problem is gone!

                            I then reinstated Reset() but extended the settling time to 5 seconds from 3. (4 was insufficient). and it now seems to function as expected. I got the 3 seconds from page 5 of the Serial Command manual but it seems to be insufficient for some functions.

                            Comments please. Maybe 5 seconds is insufficient too?
                            Last edited by TomLewis; 12th February 2018, 02:01 PM. Reason: because I found the source for using 3 seconds for reset.

                            Comment


                            • #29
                              I added a reset into my program and had a bit of a play.

                              For me 2780ms is about the go/nogo point, so 3000ms should really be enough. (the 2780ms was on windows, so could be +30ms or so due to latency)

                              Maybe your timings are not that accurate?

                              Maybe the display can't handle baud rate changes that quickly after startup (as that is not in my program, I'm just doing the same as in the code I sent you)

                              Maybe the baud rate change on the Propellor needs a 'flush' after it?

                              Dunno
                              Mark

                              Comment


                              • #30
                                It's odd that the pause after reset would be sufficient for some 4FN files but not others.

                                I'm satisfied that the problem is generally solved, even if some of the specifics could be a crisper.

                                If the delay after reset becomes critical, I'll play with it again.

                                Thanks for your help. It's been an frustrating problem with a simple solution. I'll edit the OP to summarize the solution.

                                Comment

                                Working...
                                X