+ Post New Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 28 of 28
  1. #21
    Banned
    Points: 5,417, Level: 17

    Join Date
    Jun 2016
    Posts
    1,159
    Helped
    122 / 122
    Points
    5,417
    Level
    17

    Re: Running micro and debugger to find problem with code?

    If you don't have any problem in posting the .hex file then post it with your exact circuit and I will debug it and tell what is the problem.



    •   Alt6th May 2017, 21:14

      advertising

        
       

  2. #22
    Advanced Member level 5
    Points: 25,375, Level: 38
    Achievements:
    7 years registered

    Join Date
    Sep 2008
    Location
    cambridge
    Posts
    5,346
    Helped
    412 / 412
    Points
    25,375
    Level
    38

    Re: Running micro and debugger to find problem with code?

    Thanks,
    The capture only saves what you see on the screen to a file, it will not store anything you can't also see.
    ..we did actually manage to save some data to file during one period....but we did not see anything on the black screen of realterm during this period......we were indeed trying to get data to be on the realterm screen, but we only managed this for a few minutes , and then it stopped, and we havent been able to get it back on the screen since. We would like it on the screen all the time (as well as to file), so that we can see that it is working.

    We are using windows OS....it looks like one of the later ones, at least windows 8, but i will check when back at work



    •   Alt6th May 2017, 21:47

      advertising

        
       

  3. #23
    Super Moderator
    Points: 23,188, Level: 37
    andre_teprom's Avatar
    Join Date
    Nov 2006
    Location
    Portugal
    Posts
    7,036
    Helped
    860 / 860
    Points
    23,188
    Level
    37
    Blog Entries
    5

    Re: Running micro and debugger to find problem with code?

    We can scope the ttl output of the micro, and that is always sending data......but that comes through a ttl to usb converter, and then onto the PC.....
    One of the first hypotheses that came to mind it was the possibility that the Baud Rate setting of the microcontroller was not correctly calculated; In addition, it is expected that you are using crystal oscillator on this circuit. However, the well defined behavior you've reported (stop recording after a while), induces the possibility that the issue is not necessarily hardware-related. Are you able to check if the amount of characters saved to the file is, let's say, an integer number which suggests that somewhere on system or tool such treshold is configured ( eg. a multiple 10, (sub)multiple of 1024 ) ?
    --------------------------------------------------------------------------------------------------
    Part of the world that you live in, You are the part that you're giving ( Renaissance )



    •   Alt7th May 2017, 11:08

      advertising

        
       

  4. #24
    Super Moderator
    Points: 231,355, Level: 100
    Awards:
    1st Helpful Member

    Join Date
    Jan 2008
    Location
    Bochum, Germany
    Posts
    39,939
    Helped
    12200 / 12200
    Points
    231,355
    Level
    100

    Re: Running micro and debugger to find problem with code?

    We can scope the ttl output of the micro, and that is always sending data...
    Fine, so you also checked the exact baud rate and correct framing?


    1 members found this post helpful.

  5. #25
    Full Member level 3
    Points: 3,580, Level: 14

    Join Date
    Mar 2005
    Location
    Europe
    Posts
    179
    Helped
    52 / 52
    Points
    3,580
    Level
    14

    Re: Running micro and debugger to find problem with code?

    USB-TTL converter with fake FTDI chips combined with original FTDI software driver?



  6. #26
    Super Moderator
    Points: 64,616, Level: 62
    Achievements:
    7 years registered
    Awards:
    2nd Helpful Member
    betwixt's Avatar
    Join Date
    Jul 2009
    Location
    Aberdyfi, West Wales, UK
    Posts
    10,695
    Helped
    3475 / 3475
    Points
    64,616
    Level
    62

    Re: Running micro and debugger to find problem with code?

    If it runs perfectly then stops, most likely it is configured to use XON/XOFF protocol and an XOFF was received. If I'm right, make sure handshaking is turned completely off.

    Brian.
    PLEASE - no friends requests or private emails, I simply don't have time to reply to them all.
    It's better to share your questions and answers on Edaboard so we can all benefit from each others experiences.



    •   Alt7th May 2017, 14:04

      advertising

        
       

  7. #27
    Advanced Member level 5
    Points: 25,375, Level: 38
    Achievements:
    7 years registered

    Join Date
    Sep 2008
    Location
    cambridge
    Posts
    5,346
    Helped
    412 / 412
    Points
    25,375
    Level
    38

    Re: Running micro and debugger to find problem with code?

    One of the first hypotheses that came to mind it was the possibility that the Baud Rate setting of the microcontroller was not correctly calculated; In addition, it is expected that you are using crystal oscillator on this circuit.
    Thanks, youve got a good point...we are not using a crystal oscillator, just the micro's internal oscillator...maybe this is our problem?...the micro does get well hot as its encased in a non ventilated LED enclosure with 30W of leds pouring heat into the internal ambient.



  8. #28
    Super Moderator
    Points: 23,188, Level: 37
    andre_teprom's Avatar
    Join Date
    Nov 2006
    Location
    Portugal
    Posts
    7,036
    Helped
    860 / 860
    Points
    23,188
    Level
    37
    Blog Entries
    5

    Re: Running micro and debugger to find problem with code?

    Quote Originally Posted by treez View Post
    ...we are not using a crystal oscillator, just the micro's internal oscillator...maybe this is our problem?...the micro does get well hot as its encased in a non ventilated LED enclosure with 30W of leds pouring heat into the internal ambient.
    I'm sure that this is the cause of the problem; Internal oscillators are strongly affected by temperature variation of the chip. Although UARTs are made in such a way that accept a considerable difference between remote TX and local RX rates ( up to ~5% for 8N1 ), the fact that these values are often defined by internal timers with values varying at low resolution steps, it is not improbable that the calculated baud is at the edge limit of the detectable range, instead of centered at the optimal value. The only thing that I can suggest as a work around solution is to reduce the Baud downto a lower rate, or even to experiment setup neighborhood values, but as FvM has mentioned, it is important to measure with an oscilloscope its exact value in order to know exactly what is happening to decide the appropriate action.
    --------------------------------------------------------------------------------------------------
    Part of the world that you live in, You are the part that you're giving ( Renaissance )



--[[ ]]--