Datasheet with register definitions?

  • Hi

    The datasheet has pinouts and a list of feature bullet points but not enough info to program the peripherals on the chip. Is there a plan to release a datasheet with register definitions and internal connections (e.g. register addresses & interrupt assignments)?

    The SDK may or may not cover all application needs and/or may have bugs that can be resolved via this information.

    Thank You

  • Could someone from the Kendryte staff give an official statement about if the full Technical Reference Manual with the full registers description and the peripheral functionality will ever be released or is it considered a confidential information (😞 ). It's a simple yes or no answer.

  • Because there is still no official reply I decided to post here some differences I found against the Cyclone-V document.


    • ic_fs_scl_hcnt and ic_fs_scl_lcnt registers do not seem to be present on K210
    • setting speed field of ic_con register does not seem to have any effect
    • transmit and receive FIFOs are 8 bytes deep


    mix of and

    • although K210 datasheet says that transmit and receive FIFOs are 8 bytes deep hardware reports 16 bytes depth
    • following features are NOT implemented: FIFO_STAT, FIFO_ACCESS, SIR_LP_MODE, AFCE_MODE

  • I am also waiting for an official response. It has been promised Technical Reference Manual will be published piece by piece - I don't want to buy more chips now because they will be useless without the manual.

  • For anyone who wants to start working on K210 ASAP I found that registers look very similar to Cyclone V registers (

    There are some differences so Kendryte team should provide their reference manual anyway.

  • @nathan Thanks for your response, but then what is offered is not a datasheet. Its really a marketing brochure.

    Compare your data sheet to, for example, PIC32 controllers offered by Microchip Inc.

    I must agree with other comments that this causes a problem for meaningful development and use in potential products. No matter how great the SDK development team is, they will not be able to account for all uses, scenarios and problems. Users should not have to look at opaque read/writes to control addresses in order to try and reverse decode what is happening and what other things can be done.

    I'm trying to understand any reluctance to publish this info..

    1 -- its a complex task with limited staff (but this still has to be documented for sdk development). There could be some folks willing to help out given rough info.
    2 -- there are features that must remain hidden for various reasons (other companies publish supported devices and rope off certain sensitive areas for formal NDA agreement, e.g. security fuse programming).
    3 -- there are embarrassing bugs (all chips have bugs/errata!), some known and some not yet known. Maybe you have an undocumented HCF bit (a little joke: Halt and Catch Fire)?

    Ultimately, it is your decision, so thanks for any continued consideration.

  • @loboris I raised the same query few days ago, did not get any response from Kendryte team.

    @nathan recommend their SDK over documentation. I find his comments really bizarre.

    I have two K210 boards laying around and will not do any work on them until they release full documentation.

  • @loboris I have meet the same problem and stop and wait for the full datasheet!

  • @nathan
    Are you saying you don't wont others to participate in the SDK development?
    Any serious work is impossible without a full documentation!
    If you are not planning to release the full Technical Refference manual, I'll probably stop my work on K210...

  • Staff

    @raykj Using SDK is recommended. If SDK hasn't cover your needs, please let us know.