In my opinion, burndown charts can't go negative. If you're done with your work you either keep on sitting in your chairs doing nothing which means that the burndown will stay at zero.
If you indeed do something, then that should be added to your list of tasks, meaning that the burndown will go up and then down again when you're done with tasks you added to your sprint's workload.
A sprint where the original workload has been completed before the sprint ends should show a little spike when new tasks (either single tasks, e.g. bug fixes or whatever, or one or more new user stories) have been added again once it became clear that there's room for more.
However, if this happens frequently with your team you seem to be constantly underestimating your velocity and should start committing to more tasks from the beginning. I'm not saying that it's a bad thing to be able to finish early and take on more tasks, but if this happens in a lot of sprint it is a sign that the team is undercommitting right from start, either by accident or to make absolutely sure that there's no way they will fail the sprint.
If that's okay with your product owner, so be it. If I were the product owner and I would see one team always finishing early I would try to get them to commit to more tasks right from the start. This might sound a bit harsher than it's intended to sound.