Python serial write to SAMD21 - serial breaks after one buffer sent

Log in or register to post comments
Go To Last Post
12 posts / 0 new
Author
Message
Mithrandir_
Mithrandir_'s picture
Level: Hangaround
Joined: Thu. Apr 8, 2021
Posts: 137 View posts
Location: Khazad-dûm, Middle Earth
#1
Posted by Mithrandir_: Mon. Jun 21, 2021 - 02:16 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,

 

I'm trying to send some serial data from python to my MCU. It turns out that it is able to send the 1st buffer perfectly, however trying to send additional buffers does not seem to work. It seems like the serial communication breaks after one buffer. I have to reboot the instrument in order for the serial port to start working again.

 

To clarify: the MCU is actually receiving the data as shown in the "receiving" buffer, but as you can see it is not what I am trying to send.

 

python:

ser = serial.Serial('/dev/ttymxc2', 115200)

#send full pages
for i in range(fullPages):
    page_data = [b'\x00'] * 260 #reset page
    for j in range(256):
        page_data[j+4] = data[(256*i)+j]
    ser.write("fsh_page")
    time.sleep(0.050)
    ser.write(page_data)
    receive_bytes = ser.read(260);
    print "Sending:"
    print " ".join(hex(ord(n)) for n in page_data)
    print "Receiving:"
    print " ".join(hex(ord(n)) for n in receive_bytes)
    print "Written to flash:"
    receive_bytes = ser.read(260);
    print " ".join(hex(ord(n)) for n in receive_bytes)
    time.sleep(0.1)

MCU code that is receiving the data:

else if(!strcmp("fsh_page", (char*)usart_buffer)){
            static int pageNumber = 20;
            uint8_t tx[260];
            uint8_t rx[260];
            volatile uint8_t page_buffer[PROGRAM_PAGE_SIZE+4];
            usart_read_buffer_wait(&usart_module, (uint8_t*)page_buffer, PROGRAM_PAGE_SIZE+4);
            usart_write_buffer_wait(&usart_module, (uint8_t*)
                                        page_buffer,PROGRAM_PAGE_SIZE+4); //raw
            if( flash_WriteBuffer(PROGRAM_PAGE_SIZE*pageNumber,PROGRAM_PAGE_SIZE+4,
                                    (uint8_t*)page_buffer) == true ) { //debug
                flash_ReadBuffer(PROGRAM_PAGE_SIZE*pageNumber, 260, tx, rx);

			    pageNumber++;

                usart_write_buffer_wait(&usart_module, rx,PROGRAM_PAGE_SIZE+4); //flash

			} //end debug
        }

output:

Sending:
0x0 0x0 0x0 0x0 0x42 0x4d 0x32 0x5f 0x0 0x0 0x0 0x0 0x0 0x0 0x42 0x0 0x0 0x0
0x28 0x0 0x0 0x0 0xf7 0x0 0x0 0x0 0x31 0x0 0x0 0x0 0x1 0x0 0x10 0x0 0x3 0x0
0x0 0x0 0xf0 0x5e 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0
0x0 0x0 0x0 0x0 0x0 0xf8 0x0 0x0 0xe0 0x7 0x0 0x0 0x1f 0x0 0x0 0x0 0x0 0x0
0x0 0x0 0x0 0x0 0x0 0x0 0x41 0x8 0x41 0x8 0x20 0x0 0x0 0x0 0x0 0x0 0x0 0x0
0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0
0x0 0x20 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0
0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0
0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x20 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x20 0x0
0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0
0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x20 0x0 0x0 0x0
0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x20 0x0 0x0 0x0 0x0 0x0 0x0
0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0
0x0 0x0 0x20 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0
Receiving:
0x0 0x0 0x0 0x0 0x42 0x4d 0x32 0x5f 0x0 0x0 0x0 0x0 0x0 0x0 0x42 0x0 0x0
0x0 0x28 0x0 0x0 0x0 0xf7 0x0 0x0 0x0 0x31 0x0 0x0 0x0 0x1 0x0 0x10 0x0
0x3 0x0 0x0 0x0 0xf0 0x5e 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0
0x0 0x0 0x0 0x0 0x0 0x0 0x0 0xf8 0x0 0x0 0xe0 0x7 0x0 0x0 0x1f 0x0 0x0 0x0
0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x41 0x8 0x41 0x8 0x20 0x0 0x0 0x0 0x0 0x0
0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0
0x0 0x0 0x0 0x20 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0
0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0
0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x20 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0
0x20 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0
0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x20 0x0
0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x20 0x0 0x0 0x0 0x0
0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0
0x0 0x0 0x0 0x0 0x20 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0

0x0
Written to flash:
0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
0xff 0xff 0xff 0xff 0xff
Sending:
0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0
0x0 0x20 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x20 0x0 0x20 0x0 0x0 0x0 0x0
0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x20 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0
0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x20 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0
0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0
0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0
0x0 0x20 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0
0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x20 0x0 0x0 0x0 0x0
0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x20 0x0 0x20
0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x20 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0
0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x20
0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0
0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0
0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x20 0x0 0x0
0x0 0x0 0x0 0x0 0x0 0x0 0x0
Receiving:
0x66 0x73 0x68 0x5f 0x70 0x61 0x67 0x65 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0
0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x20 0x0 0x0 0x0 0x0 0x0 0x0 0x0
0x0 0x0 0x20 0x0 0x20 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x20
0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x20 0x0
0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0
0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0
0x0 0x0 0x0 0x0 0x0 0x0 0x20 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0
0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x20 0x0
0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x20
0x0 0x20 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x20 0x0 0x0 0x0 0x0 0x0 0x0 0x0
0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x20
0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0
0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0
0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x20 0x0
Written to flash:
0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
0xff 0xff 0xff 0xff 0xff

 

This topic has a solution.

1010001010111101110111

Tags:

Tools, Compilers, Assemblers, Linkers and General Programming (ARM-related), solved
Last Edited: Tue. Jun 22, 2021 - 08:06 AM
Top
Bronze Markawneil
awneil's picture
Level: 10k+ Postman
Joined: Fri. Jul 1, 2005
Posts: 25563 View posts
Location: Basingstoke, Hampshire, UK
Posted by awneil: Mon. Jun 21, 2021 - 02:30 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

continued from: https://community.atmel.com/forum/serial-output-python-saml21-yields-garbage-data

 

Mithrandir_ wrote:
It seems like the serial communication breaks after one buffer

What, exactly, do you mean by "breaks" ?

 

How have you verified that the Python is actually sending what you think?

 

Have you used a debugger to see what's actually happening in the Python?

 

How have you verified that the SAM is actually receiving what you think?

 

Have you used a debugger to see what's actually happening in the SAM?

 

The code you've posted doesn't show how the output you've posted was generated - so how are you sure it's a true representation?

 

The output you've posted seems to be all generated at the Python end?

 

EDIT

 

You're relying on blind delays:

    ser.write("fsh_page")
    time.sleep(0.050)
    ser.write(page_data)

You need some sort of protocol to ensure that the SAM is keeping up with the Python, and vice-versa

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillator: https://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
Last Edited: Mon. Jun 21, 2021 - 02:36 PM
Top
Mithrandir_
Mithrandir_'s picture
Level: Hangaround
Joined: Thu. Apr 8, 2021
Posts: 137 View posts
Location: Khazad-dûm, Middle Earth
Posted by Mithrandir_: Mon. Jun 21, 2021 - 03:02 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awneil wrote:
What, exactly, do you mean by "breaks" ?

 

It receives the data as show in the "Receiving" buffer - not as shown in the "Sending:" buffer.

 

awneil wrote:
How have you verified that the Python is actually sending what you think?

 

I'm printing out the bytes that I am sending - that is the only way in which I have verified it.

 

awneil wrote:
Have you used a debugger to see what's actually happening in the Python?

 

In my opinion printing the bytes that I am sending is good enough - it shows me the hex values that it is sending and they are the correct values.

 

awneil wrote:
How have you verified that the SAM is actually receiving what you think?

 

I am storing the sent data on a flash memory - it is storing the values as given by "Received:". 

 

awneil wrote:
The output you've posted seems to be all generated at the Python end?

 

Yes and no, it's printed out by python, but python receives the two latter buffers from the MCU through serial. The values are verified by the fact that I have an LCD that draws the picture that I am trying to store in the flash memory. The picture is drawn but it is off by as much as you'd expect from looking at the deviation in the data i.e. I can see the picture but the colors are off.

 

awneil wrote:
You're relying on blind delays:

Shouldn't this be enough when using ASF functions like spi_write_buffer_wait? It takes care polling the necessary bits AFAIK. I don't care about the speed of this transfer as it is a done once at the initial setup of the instrument thing.

 

Investigating the data further I have discovered that every other buffer is sent and received correctly. That is buffer 0 is correct, buffer 2 is correct etc, but all the odd buffers are wrong.

 

1010001010111101110111

Top
Bronze Markawneil
awneil's picture
Level: 10k+ Postman
Joined: Fri. Jul 1, 2005
Posts: 25563 View posts
Location: Basingstoke, Hampshire, UK
Posted by awneil: Mon. Jun 21, 2021 - 03:18 PM (Reply to #3)
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Mithrandir_ wrote:
In my opinion printing the bytes that I am sending is good enough

I don't think so. It does not show what was actually sent; especially as you're sending binary data - there are many things that can get tripped-up on binary data.

 

 it shows me the hex values that it is sending

No, it doesn't you do a lot of processing to get them into a form for printing - so you really don't know what was actually sent.

 

I am storing the sent data on a flash memory - it is storing the values as given by "Received:". 

Again, you could be getting corruption in any one or more of:

  • receiving,
  • processing for storage,
  • storing,
  • retrieving
  • sending back

 

awneil wrote:

You're relying on blind delays:

 

Shouldn't this be enough when using ASF functions like spi_write_buffer_wait?

The point is, don't guess - have some actual feedback.

 

And what's this about SPI??  You never mentioned SPI!

 

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillator: https://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
Top
Mithrandir_
Mithrandir_'s picture
Level: Hangaround
Joined: Thu. Apr 8, 2021
Posts: 137 View posts
Location: Khazad-dûm, Middle Earth
Posted by Mithrandir_: Mon. Jun 21, 2021 - 07:13 PM (Reply to #4)
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The SPI is well tested, that's not going to be the problem so it's not relevant to the issue.

 

Looking more carefully at the buffers that are received I can see what is wrong.

 

values as they should be:

0x00 0x00 0x00 0x00 0x96 0xad 0xb6 0xb5 0x10 0x7c 0x20 0x0

values as they are:

0x66 0x73 0x68 0x5f 0x70 0x61 0x67 0x65 0x0 0x0 0x0 0x0 >>>> correct values start from here: 0x96 0xad 0xb6 0xb5 0x10 0x7c

It seems I am receiving some garbage values before the real values are being sent.

 

What perplexes me about this is that it is only every other buffer. The even buffers are all correct, the odd buffers are all slightly off. Seems like a timing issue to me.

1010001010111101110111

Top
Bronze Markawneil
awneil's picture
Level: 10k+ Postman
Joined: Fri. Jul 1, 2005
Posts: 25563 View posts
Location: Basingstoke, Hampshire, UK
This reply has been marked as the solution. 
Posted by awneil: Mon. Jun 21, 2021 - 07:18 PM (Reply to #5)
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Mithrandir_ wrote:

0x66 0x73 0x68 0x5f 0x70 0x61 0x67 0x65 0x0 0x0 0x0 0x0 >>>> correct values start from here: 0x96 0xad 0xb6 0xb5 0x10 0x7c

It seems I am receiving some garbage values before the real values are being sent.

 

take a closer look at that "garbage" ...

0x66 0x73 0x68 0x5f 0x70 0x61 0x67 0x65 
   f    s    h    _    p    a    g    e

Now look again at #2 ...

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillator: https://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
Top
Mithrandir_
Mithrandir_'s picture
Level: Hangaround
Joined: Thu. Apr 8, 2021
Posts: 137 View posts
Location: Khazad-dûm, Middle Earth
Posted by Mithrandir_: Mon. Jun 21, 2021 - 09:21 PM (Reply to #6)
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ooh that's very interesting and helpful, thanks.

 

I am going to try to add a loop to check for completeness and see if that does the trick

 

#send full pages
for i in range(fullPages):
    page_data = [b'\x00'] * 260 #reset page
    for j in range(256):
        page_data[j+4] = data[(256*i)+j]
    ser.write("fsh_page")
    time.sleep(0.050)
    ser.write(page_data)
    receive_bytes = ser.read(260);
    print "Sending:"
    print " ".join(hex(ord(n)) for n in page_data)
    print "Receiving:"
    print " ".join(hex(ord(n)) for n in receive_bytes)
    print "Written to flash:"
    receive_bytes = ser.read(260);
    print " ".join(hex(ord(n)) for n in receive_bytes)
    while(1): #wait for pge_done message from MCU
        ser.write("pge_done") #send message that page is done
        check = ser.read(8)
        if(check == "pge_done") #wait for response
            break
else if(!strcmp("fsh_page", (char*)usart_buffer)){
            static int pageNumber = 20;
            uint8_t tx[260];
            uint8_t rx[260];
            volatile uint8_t page_buffer[PROGRAM_PAGE_SIZE+4]; 
            usart_read_buffer_wait(&usart_module, (uint8_t*)page_buffer, PROGRAM_PAGE_SIZE+4);
            usart_write_buffer_wait(&usart_module, (uint8_t*)
                                        page_buffer,PROGRAM_PAGE_SIZE+4); //raw
            if( flash_WriteBuffer(PROGRAM_PAGE_SIZE*pageNumber,PROGRAM_PAGE_SIZE+4, 
                                    (uint8_t*)page_buffer) == true ) { //debug
                flash_ReadBuffer(PROGRAM_PAGE_SIZE*pageNumber, 260, tx, rx);

			    pageNumber++;

				
                usart_write_buffer_wait(&usart_module, rx,PROGRAM_PAGE_SIZE+4); //flash

			} //end debug
            while(1){
                usart_read_buffer_wait(&usart_module, (unsigned char*)usart_buffer,
                                        UART_BUFFER_LENGTH);
                if(strcmp("pge_done", (char*)usart_buffer){
                    usart_write_buffer_wait(&usart_module, (unsigned char*)

									"pge_done", 8);
                    break;
                }
            }
        }

I will get on top of it tomorrow morning.

1010001010111101110111

Top
Mithrandir_
Mithrandir_'s picture
Level: Hangaround
Joined: Thu. Apr 8, 2021
Posts: 137 View posts
Location: Khazad-dûm, Middle Earth
Posted by Mithrandir_: Tue. Jun 22, 2021 - 08:07 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks awneil - adding some timing loops fixed the problem.

1010001010111101110111

Top
Bronze Markawneil
awneil's picture
Level: 10k+ Postman
Joined: Fri. Jul 1, 2005
Posts: 25563 View posts
Location: Basingstoke, Hampshire, UK
Posted by awneil: Tue. Jun 22, 2021 - 08:53 AM (Reply to #8)
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Mithrandir_ wrote:
adding some timing loops fixed the problem.

More blind delays ?

 

https://www.avrfreaks.net/commen...

 

frown

 

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillator: https://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
Top
Mithrandir_
Mithrandir_'s picture
Level: Hangaround
Joined: Thu. Apr 8, 2021
Posts: 137 View posts
Location: Khazad-dûm, Middle Earth
Posted by Mithrandir_: Tue. Jun 22, 2021 - 12:50 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awneil wrote:
More blind delays ?

 

No. The python code waits for a 'ready to receive' message from the MCU before it outputs anything.

1010001010111101110111

Top
Bronze Markawneil
awneil's picture
Level: 10k+ Postman
Joined: Fri. Jul 1, 2005
Posts: 25563 View posts
Location: Basingstoke, Hampshire, UK
Posted by awneil: Tue. Jun 22, 2021 - 12:57 PM (Reply to #10)
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Jolly good - so not actually a "timing loop", then?

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillator: https://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
Top
Mithrandir_
Mithrandir_'s picture
Level: Hangaround
Joined: Thu. Apr 8, 2021
Posts: 137 View posts
Location: Khazad-dûm, Middle Earth
Posted by Mithrandir_: Tue. Jun 22, 2021 - 06:27 PM (Reply to #11)
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awneil wrote:

Jolly good - so not actually a "timing loop", then?

 

I guess not :). Not really sure what to call it but it's a handshake that makes sure that both parties are ready to exchange data. I tested a bunch of different files and it works flawlessly. 

1010001010111101110111

Top