• State Not Answered
  • Replies 18 replies
  • Subscribers 91 subscribers
  • Views 4356 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 287409
Options

CRC on the nrf52840

kongstrupp

Hello!

Regarding the CRC on the nrf52840 the specifications make it clear that the maximum length of the CRC is 3 bytes, We are working on an industrial communication protocol that we want to implement on the nrf52840. This protocol needs 4 bytes crc (crc32), is there a workaround for this? 

Thanks! 

Parents Reply
  • 0 in reply to kongstrupp

    I was thinking about writing something about timing in my reply yesterday, but I skipped it Slight smile 

    I don't know anything about this protocol that you want to use, other than that it has a 4 byte CRC. But what I know from BLE is that in this case, a SW based CRC would probably not work, since the timing requirements are very strict, and the peripheral/server/slave needs to modify the reply packet based on the incoming packet, and then generate a CRC in a very short time. So whether it will work or not probably depends on timing. I guess you just need to test and see.

    Best regards,

    Edvin

Children
  • 0 in reply to Edvin

    I see, I will try to summarize the timing scheme within the IO-Link Wireless protocol as much as I can. 

    Down below a picture of a sub-cycle between master and slave is shown. This is a scheme that show a complete communication exchange between master and slave. 

    As you can see the yellow part is the downlink (master to slave), and the green parts are the uplinks (slave to master). So a downlink is sent from the master and received by all slaves, and then, the uplinks are returned in a special order to the master.

    At the end of each uplink and downlink the IO-Link Wireless protocol requires a 4 byte CRC. Note that between each green slot, there is a red interval to avoid collision on air (guard interval). This guard interval is 8 us, which means that the master (considering this software solution) needs to be able to calculate a 4 byte CRC within LESS than 8 us

    So, we are very interested in knowing if the CPU is able to do this. Can it calculate a 4 byte CRC this fast? Is there a way to measure the processors execution time? I looked online and it seems to be a bit more complicated that I thought. Please let me know if this information that I have just provided is not sufficient for you to be able to determine weather or not this is possible.

    Thanks a lot Edvin for you inputs really means a grate deal for us 

    BR

     

  • 0 in reply to kongstrupp

    Is there a CRC after each of the green sections (before the red sections)? Or is it a CRC after the entire thing in the picture? And is the CRC dependent on the downlink, or can you generate it before the downlink?

    kongstrupp said:
    This guard interval is 8 us, which means that the master (considering this software solution) needs to be able to calculate a 4 byte CRC within LESS than 8 us

    I did not forget to answer this, but I don't know how long it takes. You would need to test this. I guess it depends on what else the nRF is doing at the time, and even if it is doing this as the highest priority I don't know how long this function call will take. It probably depends on the length of what you need to generate the CRC of. Before you ask, I don't know how large a packet you could generate a 4byte CRC below 8µs is either. You need to test.

  • 0 in reply to Edvin

    Yes there is a CRC after each of the green sections, Yes, the total length of the downlink is 52 bytes. Which means the CRC will be calculated on the 43 bytes of the downlink since preamble and syncword  does not count (5 bytes) and  i assume that you dont count CRC on CRC. So 52-9 = 43 

    Here you can see a picture of an uplink (the green slots in the picture above) and after that a D_GUARD which is 8 us 

    How do you test this in a sufficent way? I assume that you would just use the crc32_compute() function. So maybe generate a hello_world program and do something like this:

    #include <stdio.h>
    #include <time.h>       // for time()
    #include <unistd.h>     // for sleep()
     
    // main function to find the execution time of a C program
    int main()
    {
        time_t begin = time(NULL);
     
        crc32_compute() // some bytes to do CRC on
        sleep(3);
     
        time_t end = time(NULL);
     
        // calculate elapsed time by finding difference (end - begin)
        printf("The elapsed time is %d seconds", (end - begin));
     
        return 0;
    }
    this could to be a way of doing it, but it does not seem to work in nrf connect extension in VScode.
    What do you suggest?
    Best regards

  • 0 in reply to kongstrupp

    This can be one way of doing it.

    kongstrupp said:
    this could to be a way of doing it, but it does not seem to work in nrf connect extension in VScode.
    What do you suggest?

    Why does it not work? Does it not compile? Is it not able to calculate the time? 

    I am not that familiar with the time libraries in NCS. Another simple way to test this is to toggle a pin before and after the calculations (crc32_compute()), and then monitor this using a logic analyzer or an oscilloscope. 

  • 0 in reply to Edvin

    No I think the libraries does not support it. I am currently looking into a soft way of doing it, I need some kind of function that would help me do what is described above. Yes that is one way of doing it, I will have to look into it more

Related
Terms of service