First I would ask if it makes sense for you to do with an "agile" approach. If you can look at the overall project and realize that it makes more sense to do it another way, I would push back, but you may not have that option, so if you don't just ignore what I said.
I was actually in this situation at my last job at a certain silicon company. Our software product was tied to the platform/system so all of our major releases coincided with platform releases. On the software side, management really wanted to mark, "[ X ] We do Agile", so we were stuck with agile for software within a waterfall for hardware.
Just gonna spitball and throw out some things as I recall them. We had strict stand-up meetings to start the morning, capped at 15 minutes, but could end early. Do not go over the time limit, ever (ok, yes a few times is fine, but do not allow the habit to form). "What did you do yesterday, what are you doing today, and what are you blocked on?" generally each person had 1-2 minutes and once we finished the "round-table", then any pass-downs and off to work.
We would usually have 1-3 new features for each major version/release which was ~6 months, so we'd stick with 1 week sprints and pretty much remove planning meetings by filling in our work / tasks as they came up. Planning meetings just devolve into hard-ons for burn-down charts regardless of actual progress being made in software quality and feature development. We would put in refactoring and clean-up if we were about to change an area and then tackle it. I guess the point I'm trying to make with that is by keeping our sprints short, we had more opportunities to "inject" tasks that should be done without it affecting end-of-sprint results. If you had a 2-4 week sprint and realize you need to refactor something to do it right, are you going to have your tasks done at the end of the week and will it be frowned upon by management?
I don't know if any of that will be of help to you, but hopefully there's something useful in there for ya.