Hi Paul. This might be slightly off-topic for this thread, but it is connected to the Kinetis driver. Tomas - some of the things I mention that differ might also differ on the K22, if you can, please try verifying. (My way of verifying was to take a K10 datasheet+RefMan and compare against the KE04's datasheet+RefMan, especially register locations and register bitfields, but also the clock frequencies allowed for flash-programming)
On Tue, 3 Feb 2015 13:11:14 +0300, Paul Fertser wrote: >> I started working with Kinetis MK22FN1M0VLL12 > > The logic regarding bank_ordinal seems to be buggy, as this variable > is never assigned anyway. The kinetis driver really need some love... I've made a couple of 'attempts' to write or hack a Kinetis-KE driver (for the KE04), but as I'm not sure whether I should write a completely new driver or add code to the existing "Kinetis" driver, I've spent time on other things. I think that one of the things that are 'narrowing' the kinetis.c, is the "granularity". I'd prefer #defines instead of using constant numbers for this "index" value. My first attempt to write a KE-driver, was to add code to the existing kinetis.c, but ... I suddenly found it overwhelming, and started on writing a bare KE driver instead. It hasn't come far (almost just a template), though, as I don't have much time for attending to it. >> I investigated the problem further and found that programming session of >> length 1kB or less works. >> Reference manual K22P100M120SF5RM does not help here. The main problem with the KE, is that the SIM_SDID does not exist, but a SIM_SRSID takes its place, but there's also other things, such as the uploaded flash code must run on Cortex-M0 (which it seems it does, I'm not sure about the LDMIA instruction, though - it's officially unpredictable when using only a single register). There's no protection on the KE04 devices, the sector size is 512 bytes only, the RAM size is 1K only, so these also differ slightly. Apart from that, it's important to flash-program the chip at the right clock-frequency as well, otherwise it can be damaged. What would be the preferred implementation - a new stand-alone driver or a "one size fits all" ? Love Jens ------------------------------------------------------------------------------ Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ OpenOCD-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openocd-devel
