Blog / musings

Blog 14th Sept 2018 – PIC32MX170 Anyone out there trying to store persistent data in non volatile memory on a PIC32MX chip and finding it a bit tricky? I'm using a PIC32MX170F256D chip and needed to store a handful of 32 bit words in non volatile memory so that a system I'm working on in my spare time could maintain state when turned off. The process isn't too bad so long as you get a couple of key concepts under your belt. On a PIC32MX170 chip, program memory is made of flash ram. You normally wipe all this memory when programming the chip... but the chip also provides a mechanism to erase/write sections of this memory using run time self programming (RTSP). This feature means that your program code can use program memory to store data that must persist after the machine has been switched off. Using flash memory does have a downside in the sense that after many write cycles the memory becomes less reliable - and so care is required to only update the memory as infrequently as possible. There are even some algorithms that deliberately use two or more pages to spread updates so that you can reduce the total number of updates to any one block. For users who only occasionally write to flash, this limitation may not present much of a problem. Anyway the problem is how is it done... given microchip documentation is not overly helpful in explaining the process.
Flash Page Size

The first thing you need to figure out from the Microchip specs is the flash page size and row size. Generally you'll find these in the synopsis overview document for the chip. In the case of a PIC32MX170F256D chip - the page size is 1024 bytes (the row size is 128 bytes). What this means (and expressing this as 32 bit words instead of bytes) is that each page of flash ram is sized as 256 words and organised as 8 rows of 32 words. The page size is significant because it is the smallest size of program memory that can be erased as one complete block. If a flash ram location contains the value 0, then you'll always be able to write a 1 to that location... however if it contains a 1 you generally won't be able to write a zero without first erasing the flash ram. Given the smallest block of flash ram that you can erase is a page you can probably see the significance of knowing what the page size actually is.

I'm aiming to use a single page of 1024 bytes (256 words) to hold the persistent data for this project. I'm going to place this at the top end of the program memory... and that's the second thing you need to find out - namely the address limits of program memory... which will again be confirmed in the synopsis document for your particular chip. Have a look at the memory map and in particular the virtual memory map for your chip and find the program flash section in KSEG0. For the PIC32MX170 this extends from 0x9D000000 to 0x9D03FFFF. So if we want to reserve a 1KB block at the top end of that range, the lowest address of the 1KB block would sit at 0x9D03FC00.

Assuming you're using an MPLab XC32 compiler, the next step is to reserve this 1KB block of memory that we've decided to use for this project. Remember this is a single page of flash ram for this PIC32MX170 CPU. When we declare the block to the compiler we need to force the XC compiler to place this at the top of the memory range. Using XC compiler directives the code to do this is:- #define NVM_STARTADDRESS 0x9D03FC00
uint32_t __attribute__((address(NVM_STARTADDRESS),persistent)) myflash[256];
Note that the type is defined as an unsigned int (32 bits) and the length is set to 256 (ie: a total of 1024 bytes). It is worth knowing that you can't add a definition to the values using something along the lines of = { Val1, Val2, ..... Val256 }; as the compiler will generate an error. This means that this block of data will be erased every time the chip is reprogrammed by MPLab and so when the code starts running immediately after programming the chip - it could test for a known value (or signature) in for example the very first word position. If that value isn't found, then the code could write a complete set of default values. Therafter every time the chip is power cycled, the values will all be present. I simply wrote the serial number into the first word of the block of flash memory as my test signature. The code checks this every time the machine starts.
Writing and reading a value is then easy using either of the two following functions and where the indexes are for 32 bit words. Index zero would read/write the first four bytes (0,1,2,3) in the flash ram block while index 1 would read/write bytes 4,5,6 and 7 in the memory block. // Function used to read a word from the NVM memory block - located at the top end of the program memory range
unsigned int ReadNVMWordAtIndex( int NVMWordIndex ) {
        unsigned int *e = (void*)((NVM_STARTADDRESS) + (NVMWordIndex * 4));
        return( *e );
}


// Function used to write a word to the NVM memory block - located at the top end of the program memory range.
// Note that this function assumes that interrupts will be disabled on either side of a call
void WriteNVMWordAtIndex( unsigned int Data, int NVMWordIndex ) {
        NVMWriteWord((void*)((NVM_STARTADDRESS) + (NVMWordIndex * 4)), Data);
}
Armed with these two functions a typical write to flash ram (including the all important page erase) would look as follows:- INTDisableInterrupts();
NVMErasePage((void *)NVM_STARTADDRESS);
// Now write a test value to the first four bytes in the flash ram (index 0).
WriteNVMWordAtIndex( 0x12345678, 0);
INTEnableInterrupts();
Interrupts are disabled before a call to the erase page and any flash ram write operation. I'm using the 32 bit library support for the PIC32MX170 chip (PLIB) - which helpfully takes a lot of the donkey work out of figuring out the specific register access required to drive these functions, although I have to say it makes a great deal more sense if you've carefully checked the synopsis document and the flash programming supliment document before you start. Once mastered I have to say that the process works very well.
Comment
7th Sept 2018 – 2.4Ghz communications In my spare time in the evenings, I've been looking at an embedded system involving two 40Mhz CPU's. I'm using PIC32MX170F256D chips with a max clock rate of 40Mhz. Unlike some of the older 80Mhz 340 PIC32's I've worked with in the past, these newer 170 chips have more consistent and reliable silicon and also better packaging options. One of the really elegant features is a pin-for-pin multiplex system for much of the internal I/O, which permits the software to control which internal I/O signal(s) gets connected to which physical pin(s). If you don't need one of the UARTs for example, instead of tying up an I/O pin pointlessly you can reuse the physical pin for something else. As a result, these chips actually come in a 28 pin DIL package... which is really very rare. Anyway - one of the CPU's is set to measure modestly fast events and then report the relative timing(s) of the events to a 2nd CPU tasked with generating a pretty display and to calculate some basic stats such as the standard deviation, mean and the like. A problem was to figure out a suitable means of communication between the two CPU's, given one unit might be randomly moving around within a couple of yards of the other. 418Mhz transmitters and receivers were considered but two way comms is hard to make work well - and they have very little in the way of comms protocols for data checking and packet sending. IR transceivers were looked at as well, but bandwidth isn't great and their sensitivity to directionality made them very difficult to use.
NRF24L01 Break Out

Over the last couple of years I've seen a number of 2.4Ghz transceiver boards based around the NRF24L01+ chip and usually aimed at the Raspberry or Arduino market. Although there are some restrictions at the high end of the transmission frequency range when these are used in the US, these devices otherwise have a worldwide licence making them particularly attractive for short range comms between digital systems. In early tests at data rates of 2mbs, I could establish reliable comms out to around 30 feet - and it didn't overly matter how many walls or floors lay in between.

Hobby folks generally drive them with aftermarket driver scripts, offloading the problem of having to figure out the nuts and bolts of the chips operation. Thats all fine and good but you'll never really learn much about a chip if that's your approach. Initially I wrote my own C library to implement the small number of commands built into the chip (read/write register, read/write payload etc) in order to assess some very limited tasks such as sending a 4 byte buffer from one chip to another under interrupt control. I found it fairly easy to get them to work... but harder to make the comms robust and reliable so that millions of data packets could be successfully sent even while errors were occurring.

After getting around a quarter of the way through my own library I stumbled on a library written by a bunch of bright young things at Cornell university - and with no licence restrictions posted. Their library is incomplete and doesn't provide support for any of the newer ACTIVATE commands (R_RX_PL_WID nor W_ACK_PAYLOAD) which interestingly open the door to all sorts of possibilities with regard to full duplex communications (they are easy commands to add if full duplex is your bag). The library was also configured to use different SPI, control bits and interrupts than I had used in my PIC32MX arrangement... but don't let that put you off - as it is trivial to recode and the library is clear enough to make that process easy. The documentation is frankly awful (considering who wrote it), with typos and a number of very confusing mistakes, but it is adaquate enough to convey the general idea. I ditched the documentation and butchered the library ending up with a pretty reliable NRF24L01 interface in C.

If you have a look on fleabay or other sellers you'll find it easy to source break out boards for the NRF24L01 from any of a gazillion different manufacturers (most are Chinese). These generally low cost boards extend the I/O required to drive the chip (usually to an 8 pin berg strip) and provide a basic 2.4Ghz antenna with a decent ground plane. As with all aftermarket kit, the quality can be a little variable - and these boards often do far better if a good sized tantalum capacitor (around 100uF) along with a 0.1uF decoupler are used across the rails. The NRF24L01 supply is 3.3volt, but the inputs are actually 5v tolerant.

Hats off to the manufacturer Nordic for a cracking design. It certainly stuck in my mind as a candidate for future projects and so rang a bell as a potential solution for this two CPU comms problem...

The chip is controlled using an SPI bus consisting of six signals. For any engineers unfamiliar, don't worry, the heart of an SPI system only requires three signals given it is simply a shift register arrangement, extending to the outside world (a) the output from the last stage of the register, (b) the input to the first stage and (c) the clock. As the clock runs, whatever had been written in parallel to the shift register, will be serially output on the output pin, while whatever data is presented on the input pin will be shifted into the register at the same time. So n clock pulses later, the output will have sent n bits while n bits (presented on the input) will be sitting ready to read from the shift register. PIC32MX chips usually build in 1 to 4 SPI interfaces and allow variable width SPI (8, 16 or 32 bit) - but for the NRF24L01 32 bit SPI transfers are required.

Three other strobes are required... two are outputs from the controlling CPU (inputs to the NRF24L01) and one is an output from the NRF24L01. The first of these is an active low chip select signal (called CSN) which is asserted by the controlling CPU whenever the SPI is being used to read or write data to/from the NRF24L01. The 2nd signal called CE (chip enable) is active high and is used to switch on the transmission / reception sections of the chip. The third and last signal is an output from the NRF24L01 and is used to raise interrupts in the controlling CPU. This signal asserts after data has been transmitted, received or when the maximum number of retries have been exceeded... yep, you read that right. This little chip has a protocol built in that demands an acknowledgement packet after a transmission and it will retry up to 15 times, with a configurable delay between retries if that ACK isn't received..

Cornell University Library
NRF24L01 Development Environment

Experiments started with small packets sent one way only after which code was extended to provide two way comms. A key issue with any comms system (and these chips are no different) is avoiding deadlock. If for example you build a very simple test system, consisting of two CPU's where CPU-A waits until it can transmit and then sends a value to CPU-B which is sitting waiting until data arrives. Once it does, CPU-B does something (ie: increments the data value) and then waits until it can transmit before sending it back. Meanwhile CPU-A has flipped into receive mode and is siting waiting until it receives data. Once it does, the whole process repeats. All well and good, but in tests, I found that if I didn't take advantage of any of the built in auto acknowledgement features, I'd see maybe 5 to 60 transfers before both sides locked up. No great surprise, for if one single transmission gets lost, both CPU's will end up fat dumb and happy waiting for the other to send a data packet... that never arrives. Deadlock...

If a data application requires data accuracy (some don’t) then three strategies help cope with this problem.
  • Take advantage of the enhanced ShockBurstTM feature built into a NRF24L01 chip. ShockBurstTM is a protocol that forces the NRF24L01 chip to wait for an acknowledgement from the far end and not to proceed until after that ACK has been received. The chip will retry a fixed number of times but if it ultimately fails to get that all important ACK, it will report the fact to the caller, which can then deal with the problem.
  • If you're using data packets much larger than around 16 bytes, you should use the larger CRC error checking value the chip allows (2 bytes instead of 1 byte). Cyclic Redundancy Checking is a simple polynomial applied to all bytes in the packet and used to detect corruption. Calculated when the packet is first sent, it is checked at the other end to establish the packet hasn’t changed. The largest number of bytes in a packet is 32 – but note that the chip can cope with variable length packets consisting of any length from 1 to 32 bytes
  • On the controlling CPU, you must not code any function so that it can lock. For example it must not be possible for an imaginary function, lets call it “GetMyData()” to sit forever polling some kind of flag somewhere that confirms if data has been received. The problem with this is that if the flag never asserts, then the GetMyData() function will loop forever. Instead, you need to frame that flag testing operation within an outer loop that monitors how long the process actually takes and forcibly aborts the process if it takes too long.
  • Another issue to consider is timing. The NRF24L01 chips will retry until ACK's are received - so effectively there are two distinct processes going on. The CPU tells the NRF24L01 to do something and then the chip will take time to complete the task. If the process fails due to the need to retry, more time will be required. Imagine you've built a system with two of these devices and where a command can be sent from A to B such that B will respond with some sort of data. Lets say A sends command N which for some reason fails. At that point if A gives up on sending command N and sends command N+1 there is a possibility that the response it will receive will actually be the older response intended for command N - given that the NRF24L01 will have been busily retrying in the background and off course, might succeed. It's a fairly standard overrun problem but it does need some thought during development. In tests on my development systems here I found this fault would occur quite randomly and usually after millions of packets had been successfully exchanged... and it was simply down to the relative timing of the sending of test packets.
My spare time project is a work in progress, but I have to say I am quite astonished at just how good these little NRF24L01 chips really are. Good job Nordic. Comment
19th Aug 2018 – Care with unsecured collets I came across Yong Heng compressors last year. Manufactured in China, these very high compression machines generally cost around £250 and provide air shooting enthusiasts with the facility to compress their own air, up to around 300 BAR. I bought one last December because I was having to visit local diving (Scuba) shops way too often to fill my air tanks - which is both expensive and inconvenient. I now use this pump regularly to fill my pre-charged pneumatic (PCP) air rifles whenever I shoot metal plate targets at the club I belong too. They are very useful little tools to have, but they do need a little fettling and care to make work well and safely. I've been using the pump for the last 9 months without any problems. I regularly service it by changing the oil and replacing the filters and O-Rings. I also use an additional molecular sieve filter in order to remove moisture - which over time would otherwise damage the internals of an air rifle. Last week, I noticed that instead of taking around 6 minutes to fill a 0.35 litre container from 200 to 300 BAR, it was now failing to exceed 275 BAR, no matter how long it was left running. I stripped the filters, changing all the cotton tampon elements just in case they were clogged and I also replaced the O-Rings on the molecular sieve just in case there was a leak - however after running the pump for 12 mins I confirmed that it still couldn't exceed 275 BAR. Yong Heng Pump I always use a blower fan to provide extra cooling for the piston cylinder as the pump runs – so after turning that off, I ran the pump into a short hose with a blanking plug... at which point I immediately heard a leak around the burst protection safeguard bolt screwed into the main output manifold (see pic above). After unscrewing that protective device I found that it is made from three parts – the first is the threaded body (left), the 2nd is a thin flat burst-disc fitted inside the body and the 3rd is a brass collet designed to compress the burst disk into place when the body is tightened into the output pressure manifold. The three are shown below – with the burst disk in the middle (it had to be gently punched out in order to remove). Yong Heng Pump - Burst Disk In this case, the disc (in the middle of the above pic) had over time deformed into a slightly domed shape. As soon as the pump pressure exceeded around 200 BAR, there was enough force to bypass the deformed disk and vent to the atmosphere. Changing the burst disk should be easy (the manufacturers of the pump ship it with five or so spare). Unscrew the threaded body, remove the brass collet from the head and replace the flat burst-disk. Refitting is the reverse... apart from one really huge gotcha, which unfortunately, I walked straight into...
Yong Heng Pump - Burst Protection Bolt

The collet (arrowed in red) is a relatively lose fit in the end of the main body. In normal use the body of this bolt threads horizontally into the manifold. Can you see what the problem was? Unless the collet is somehow locked into place, then as the body is screwed home there is a risk that the collet will rattle free and drop unseen into the bore of the manifold. At that point if you tighten the head, as I did, you'll crush the collet.

Oh dear, what a rookie mistake to have made...

I removed the threaded burst disk protector and realised that not only had I crushed the collet but I’d also damaged the countersunk body of the manifold. So at that point I removed the manifold from the pump completely so I could get proper access to it. A 5mm HSS drill bit in a pillar drill was used to clean the bore of the manifold... removing the bare minimum required to clean the base of the bore. The crushed collet was ruined, completely misshapen, there would be no compressing it back into shape. I didn’t have any suitable brass stock to machine my way out the problem, but I did have some 10mm copper bar – and so started the process of turning a replacement collet.

The newly machined copper collet is 0.2775” in diameter, centre drilled with a 4mm bit and with a front side shoulder cut to 45 degrees leaving a flat of just 0.0255” to meet with the drilled shoulder in the aluminium manifold. The overall height isn’t shown on the paper - but in the end I found 0.12” worked well. I generally tend to use inches rather than metric - simply because I'm more used to working in thousands of an inch of precision.

On inspecting the main body – I realised that the base of the threaded end of the body was a little rough – and so turned that to cut off the bare minimum required to clean it up. That resulted in a body length (without collet) of 0.5370”.

Yong Heng Pump - Copper Crush Bush
With the burst disc fitted into the main threaded body and the new copper collet fitted into the head the end result looked as follows:- Yong Heng Pump - Burst Protection Bolt Rebuilt After carefully refitting all the hardware – I reverse pressurised the manifold to 280 BAR using my large 3 litre reservoir to check for leaks. Satisfied that the manifold was holding, I then replaced the oil. The pump had only actually run for around 4 hours since the last oil change which should occur on a 10 hour cycle, but as it was accessible and on the bench anyway, it made sense to tackle this at the same time. I then ran a pressurisation cycle up to 300 BAR with just a closed pipe... without any problem. The following day I pressurised my 0.35 litre bottle from 180 BAR to 300 BAR in 7 mins – which is slightly longer than I’d expect – but only by a minute or so. We'll keep an eye on things over the next couple of weeks - but fingers crossed this newly machined collet will do the trick. Comment
7th Aug 2018 – Music Hooverphonic are a band I've known about for years and I have a couple of their albums on my iPod. I found myself trawling youtube the other day looking for something to do with house DIY of all things but randomly stumbled on a concert Hooverphonic filmed at the Koningin Elisabethzaal hall back in 2012 and uploaded to YouTube. In English it's the Queen Elizabeth hall located in Antwerp in Belgium (logical really, given the band hail from that part of the world). The concert is unusual because it featured a full sized orchestra... along with a proper film crew and so if you're a fan, the result is pretty good. Virtually all the concert is on YouTube split into separate vid's. 2-Wicky sung by the enigmatic Noémie Wolfs was a bit of a treat to discover. There is something that reminds me of John Barrys work in the sound, sort of bond like, while Noémie seems to command the stage with an elegance way beyond her years. Comment 6th Aug 2018 – Precision Grouping As a younger man, my dad enjoyed around 2 years of training as a “sharp shooter” in the army – which in modern parlance might be described as sniper training. I have no recollection of what rifles he used, nor of the specifics of his training – but I know he was good. I do have a vivid memory of the two of us visiting air shooting galleries at funfairs when I was a kid and him teaching me how to improve my chance of winning the fluffy toy. A few years after the loss of my dad, I got a strong urge to explore sports air shooting a little further. I found a suitable club and after a few phone calls and following a safety induction course, became a probationary member. While on probation, experienced members vet you while you shoot on the range, assessing both your safe handling skills and the way you behave. That's the time you can make genuine mistakes but where other more experienced people can step in both to correct and educate. I count myself very lucky because the club turned out to be really exceptional, catering for all the important air shooting disciplines and attracting a friendly group of people from very different walks of life. Originally, my intention was to train myself within a supervised club environment over the course of a year to learn to properly and instinctively handle air guns safely. After that, I planned to swap to clay shooting with shot guns. But as sometimes happens with long term plans, I found the discipline and engineering involved so interesting and challenging that 5 years later on I still haven’t moved on. UK legal limits for the muzzle energy of air guns is cut and dry - for a small air pistol the limit is 6 foot/lbs and for a longer air rifle, 12 foot/lbs. The foot/pound measurement captures both the speed at which the projectile flies as well as its weight (often measured in grams or more commonly grains). In order to keep within UK legal limits, a typical .22 pellet (15.89 grains) must travel at less than 583.1 feet per second (FPS) when shot from a long rifle, while a lighter .177 pellet (8.44 grains) can fly at 800.1 FPS. So what does that actually mean... well, by any standard UK air rifles are really very low power devices. You could easily throw a brick with more energy, while a crossbow will deliver 10 to 20 times the amount of energy. But, any tool, regardless of it being a car or a kitchen knife can cause irreparable harm if handled irresponsibly. Air guns are no different in that regard. For the responsible air rifle user, tools capable of accurately measuring muzzle speed are always in the back pack. For an engineer, tools capable of measuring energy over time, help identify 'drift' (which will directly impact accuracy). The same engineer might observe changes in performance linked to changes in temperature, or might find the point at which air pressure in the rifle reservoir tapers off but which results in a muzzle energy peak. Other tools might provide a way of judging how well pellets group at a target by accurately detecting points of impact without having to use card sheets – and off course there are other interesting possibilities. With roughly 5 years shooting experience under my belt, the potential for electronics to provide useful tools has been clear from day one and so an old friend and I have been hashing out some ideas on paper as to what sort of useful tools we might build. Early days yet, but keep an eye on my web site www.PrecisionGrouping.com for more details. Comment 2nd Aug 2018: Social Media These days I find myself wondering about the cons of social media rather more than the pros. So much so that I am now actively considering ditching the whole lot. I use Faceache a fair bit and for two main reasons. I want to keep in touch with family and friends resident in other countries. Conversations with the immediacy that faceache brings just wouldn’t be possible any other way. The second reason is because I can talk engineering with other like minded hobbyists. But I've always felt that Social Media networks have a shelf life (something the recently tumbling share price of the Zuckerberg empire supports) but more and more I also find myself weighing up its importance within my life and without just sitting there glued to a constantly changing and updating news feed page packed full of adverts... which brings to mind a meme I recently spotted (ironically) on facebook (see below)... Quote Twitter isn't much better, often feeling more like an echo chamber... or a sometimes rather unpleasant group think amplifier. Brevity isn’t always a good thing, as Twitter with wearying regularity demonstrates. I understand that every time you use one of these services you are effectively trading personal exposure... but these days the personal cost is ramping up with misguided advertising, politically motivated targeting, censorship of ideas, misuse of your data (without any say) - and all in the face of authorities powerless to call anyone to account. Still pondering, as I would very much miss chatting with friends in far away places Comment 28th July 2018: Password Protection While reading another software engineers comments about passwords a few weeks ago, I got to thinking about my own personal password policy and why (at least to my knowledge) I've never had any problems. Yes I realise that's a dangerous claim... by definition who can ever be 100% sure they've never had a problem with a cracked account. I have accounts with dozens of internets giants - and unfortunately I know at least two who have been successfully hit in the past resulting in me (and millions like me) being advised to change our passwords... (I wonder how many folks out there simply ignored that suggestion anyway?) So what do I do to avoid running into problems with these pesky things. Well, it all starts with a mindset best described as... don't trust anyone with your data. Don't use 3rd parties to manage your credentials So many of these so called secure services have been opened up to attack (even big players like LastPass have been hacked) and the fact that they apply across so many different platforms probably increases their vulnerability to the umpteen vectors an attacker can use. SQL injection is a good example - because attacks using this technique really shouldn't ever work, given SQL has provided parameterised stored procedures for decades... and yet so many web sites inexplicably choose not to use them. I use the same line of reasoning when it comes to the cloud. I understand the advantage of posting data on a remote server, because it makes it available everywhere... but it also makes it available to anyone in the company hosting the box and you’re assuming that whoever coded the front end knows about things like parameterised stored procedures. It’s a little like leaving the car keys for your brand new Tesla with valet parking... probably safe, but check the milometer. Use a desktop tool to manage your passwords I use a desktop tool to manage all my passwords – and which has a reasonable (but not unbreakable) level of symmetric encryption built in (256 AES). The particular app I choose had versions for MS desktop, Android and Apple – and all of them can be synchronised. The UI is a bit basic, but sufficient to store fixed fields (like usernames and passwords) and can also cope with detailed notes - useful if you're applying for and installing SSL certification on different web servers. That password manager has one password in order to open it – but on my desktop, the manager is actually stored inside a 2nd level defence – namely a fully encrypted volume of data that must be mounted with its own password in order to gain access. I use the excellent open source VeraCrypt software – and the volume it produces becomes my first line of defence against some 17 year old house thief who simply breaks into my house and steals an entire machine. Two passwords get me into the desktop and thereafter every single password I use for any online service is complex - see next point. Use complex passwords for every account Years ago I wrote a simple piece of software to generate random combinations of letters and numbers within specific limits (length etc). I use this to generate every single password I ever make. The fact that all of these passwords are stored in a manager, inside an encrypted volume, means that I only have to remember a pair of passwords to get access to anything I want. Password Maker Don’t use browser password managers As otherwise that 17 year old house thief we mentioned earlier might find himself having a really good day. Backup your password managment system The encrypted volume I use to hold anything remotely sensitive is backed up in four different places - one of which is completely off site. I have daily backups, twice weekly backups and a monthly backup. Keep the software up to date An independent analysis of VeraCrypt revealed a number of security flaws in version 1.19, which were corrected in version 1.20 and 1.21 - demonstrating why it is important to keep this kind of foundation software up to date. Keep in mind that the scrutiny open source software endures is a really very good thing from your point of view. Other smart folks are finding those weaknesses... and fixing them. Make sure you take full advantage of their hard work. Final thoughts My system isn't perfect. There are some weaknesses - but these are relatively localised - and better still, the systems I have in place work for me. My discipline copes well with the burden this adds - and so I'm used to having to take two steps before I can log into my electricity supplier for example. You need to find what works for you, but with a clear understanding of what the worst case could be... you know, that moment your face turns white, you break into a sweat and say out loud, "oh no". Comment